Ethernet Addressing Question

[BobLfoot 301]

Hey community, looks like I finally get hardware from this century. I have two new projects coming after the first of the year. The first project will be to convert twin PLC 5's running with RIO drives to Controllogix with Ethernet PF40 and PF70 drives. The second will be to replace DC Drives with PF40's and 70's using Ethernet Drives and Safety PLC I/O Modules. Corporate I/O dictates the addressing be 10.10.x.y where X is the Slot of the ethernet card. Each Drive/PLC Network is isolated from the Plant LAN and uses RA's managed switch. So a PLC with a ENBT card in slot 7 will be 10.10.7.0 the first switch 10.10.7.1 and drives and remaining switches will run 10.10.7.2 thru 10.10.7.254. Now the question - is 10.10.7.0 a valid address or is it in violation of some addressing minutia. BTW - for those interested the project with Safety I/O will have all safety modules on their isolated network and drives and analog I/O on a second ethernet net. All Maintenance Foreman are also being given training on the RA Managed Switches as Local IT will not be tasked with supports and maintaining them.

[JeffKiper 9]

Bob I don't know about the addressing. What happens when you have 2 different systems with the ENBT in slot 1 does the 10.10.1 change to a 10.11.1? Just something that I see could be a problem.

[BobLfoot 301]

Each System will be 10.10.1 but since a system covers an entire machine / line the two 10.10.1's will be in different physical locations. Besides a slot 1 ENBT will be a 172.X.Y.Z as the first ENBT Slot is SCADA. A drive ENBT will be in slot 2 or greater. Actually on the one system going in Slots 0 thru 3 are L63 CPU's ; Slot 4 is the SCADA ENBT {172.X.Y.Z} ; Slot 5 is the 1756-CNB {Picking up 1771 chassis as I/O} ; Slot 6 is the 1756-DHRIO {picking up Thrid Party Scale COntrollers which don't do ENET} ; and Slot 7 is the 1756-ENBT for the drives.

[Gerry 13]

10.x.y.z addresses are private similar to 192.x.y.z and are typically used for networks within factories. Your fun starts when you decide you want more status from the drives than is provided by the default I/O assemblies.

[paulengr 44]

No. Hosts cannot be numbered 0 or 255, so x.x.x.0 is illegal. Class A nets can't be 0 or 255 either. You can stick 0's in the remaining octets but as a general rule since nobody remembers all the various nuances octets 0 and 255 are usually avoided altogether. Just reading through the rest of your description, it sounds like you are doing a gross overkill on everything. You are upgrading from RIO to Ethernet, going from at most 320 kbps X 4 = 1.28 Mbps to a 100 Mbps system. Your excessive use of adapters and 4(!!) processors sounds like overkill to me. If possible, I'd just get rid of the entire 1771 chassis as well and replace it with either a 1756 chassis (if the I/O density is high enough to warrant it) or a 1794 panel instead. I believe that you can get some special IFM adapters that allow you to plug 1771 swing arms directly into a 1756 chassis so if these are available for the I/O cards in question (ask AB about this), you could actually literally leave the wiring in place on the existing swing arms and just replace the chassis. No Controlnet needed. One of the irritating things that you will find with Controlnet to some degree, and especially with DHRIO cards is that once you program everything, you cannot change I/O configuration in online programming. With Ethernet, you can actually add/change I/O even while the system is up and running, same as you'd do online programming for the code itself. I also would not consider using your addressing scheme as it sounds like very big trouble down the road. The problem is that if you ever have a need to integrate networks, you have a huge mess on your hands because you've got to renumber huge amounts of your network and causing chaos in the process. The reality is that the entire 10.x.x.x address space is open to you and there's no reason to do what you are doing since clearly nobody else is using the 10.x.x.x subnet in your operation. You'd be much better off as a minimum if you say numbered your PLC's and use the second octet for that purpose, so that addresses would be 10.x.y.z where x is the PLC number, Y is the slot number (sticking with your scheme), and z refers to the devices. Frankly given the fact that you will eventually run out of CIP connections anyways well before you are probably going to use up your IP number space, I see no reason not to use 10.10.x.y where x is the PLC number and just number devices consecutively with "y". Perhaps you could sort of subnet this by prefixing a decimal number onto y..."1-99 = first network, 100-199 = second network, 200-254 = third network". At this location, we do it based on 10.x.y.z: The "x" is the plant number. This is fixed per site. The "y" is the department number. This can (and has) been divided into a few sub-departments since some departments have far more hardware than others. We start each department with an even 10's (100, 110, 120...) for this reason. So for instance the mine was split into 130, 131, and 132. The IT (PC) network uses addresses 1-99. The PLC networks use addresses 100+. The "z" is what's left. We number everything pretty much sequentially since this address space is fairly dense. Each of the above "subnets" is saved as a spreadsheet organized into directories in a single common directory organized by department. We can have lots of "numbering authorities" who do not need to interact with each other because it is very easy to allocate and stretch the numbering system out over time.

[BobLfoot 301]

You miss the point that we already have a plantwide network for PLC's - three of them actually all in the 172.30.X.Y flavor. The corporate mandate is that the 10.10.X.Y is reserved to inside a single machine. NEVER will 10.10.X.Y be bridged from one system to another. NEVER. We'll see how long that lasts as you expertly point out.

[Rod_Hackney 2]

Pauleng makes a good point about 1771 I/O. Our local AB distributor was pitching the special IFM adapters that allow you to plug 1771 swing arms directly into a 1756 chassis for a few PLC5 upgrades we have scheduled. Getting rid of the 1771 I/O structure is a good idea if it can be done in your project.

[semilogical 0]

Bob, I was going to tell you that I tried using x.y.z.0 and it didn't work. Typically I set up any ethernet TCP/IP's using the industrial standard 192.168.x.x. When I deliver the project to the customer we adjust the IP's to fit with their plant standard. It's typically as varied as the number of hairs on your head at any given moment. Our old company architechture(probably spelled wrong) was 10.10.x.y. When we were bought out the new corporation added us in to thier structure. They have over 100,000 users on their intranet. Now we are up in the 1xx.1xx.100.xxx range. The good news is that we were able to get connected directly to our PLC's on the plant floor some 35 miles from the office. Saves driving time like you wouldn't believe. Is there someone here that can define the subnet to me? I normally get a default of 255.255.255.0 for my projects. Lately I've seen some different iterations of the number, i.e. 255.255.248.0 or 255.255.0.0 It doesn't make sense to me and I've not been real successful in finding anyone willing to give me an answer. Have fun all, TCP/IP is either the greatest thing in the world or it's a monsterous trap to drive us all crazy!

[BobLfoot 301]

At their simplest level IP addresses and Subnet masks are binary numbers. If you represent each octet of the addresses and the subnet as a binary numbers wherever the mask is a 1 both addresses must match to communicate without a gateway. I'll give a simple example. with Three IP Addresses and Two Submet Masks IP Address A - 1.1.1.1 IP Address B - 1.1.1.2 IP Address C - 1.1.2.1 Mask 1 = 255.255.255.0 Mask 2 = 255.255.0.255 REPRESENT THESE AS BINARY YOU GET IP Address A - 0000-0001.0000-0001.0000-0001.0000-0001 IP Address B - 0000-0001.0000-0001.0000-0001.0000-0010 IP Address C - 0000-0001.0000-0001.0000-0010.0000-0001 Mask 1 = 1111-1111.1111-1111.1111-1111.0000-0000 Mask 2 = 1111-1111.1111-1111.0000-0000.1111-1111 Lining up Mask 1 with all three addresses 0000-0001.0000-0001.0000-0001.0000-0001 = IP Address A 0000-0001.0000-0001.0000-0001.0000-0010 = IP Address B 0000-0001.0000-0001.0000-0010.0000-0001 = IP Address C 1111-1111.1111-1111.1111-1111.0000-0000 = Mask 1 IP A can Communicate with IP B but neither can communicate with IP C Lining up Mask 2 with all three addresses 0000-0001.0000-0001.0000-0001.0000-0001 = IP Address A 0000-0001.0000-0001.0000-0001.0000-0010 = IP Address B 0000-0001.0000-0001.0000-0010.0000-0001 = IP Address C 1111-1111.1111-1111.0000-0000.1111-1111 = Mask 2 IP A can Communicate with IP C but IP B cannot communicate with IP C also IP A cannot communicate with IP B

[paulengr 44]

Your network model completely breaks down the moment that you need another processors for more tasks, connections, etc. This forces you to have a second rack, and now your corporate model fails completely because you can't bridge the networks. Second, you've totally destroyed the ability to access the corporate network in the field where you may have all of your reference files, etc. stored at. It also makes implementing RS AssetCentre more difficult, something you will want once you have multiple programmers and/or troubleshooters running around your networks. This stuff is all covered in RFC 1918 (RFC's contain internet standards, kind of like NFPA, NEC, IEC, IEN, ISO, NIST, etc.) More importantly, originally, there was a very fixed, rigid structure for subnetting across the entire internet. It seemed like there were plenty of IP addresses. However, we are close to running out of IP addresses. As a stop gap before it becomes necessary to move the entire internet over to an IPv6 structure (with I believe 8 octets), the original rigid number assignment structure was done away with. Extensive use of firewalls, proxies, and NAT's, has further pushed off that magic date since there is now extensive sharing and reuse of IP addresses. The convention is to assign subnets from left to right, and from most to least general. So 10.x.x.x has 24 bits for a possibility of 16,777,216 nodes, minus the "invalid" ones (those with 0's or 255). 10.10.x.x has correspondingly only 65,536 (minus again the 0 and 255 values). From a corporate point of view, there are 3 subnets which are nonroutable. That is, any time packets with these IP addresses end up on the internet, they will be summarily deleted. This makes them perfect for industrial LAN use. They are: 10.x.y.z (mask = 255.0.0.0) 192.168.x.y (mask = 255.255.0.0) 172.16.x.y to 172.31.x.y (mask = 255.240.0.0) If you were to run with isolated I/O networks and assigning things in the order of 10.x.y.z where x=department, and y=PLC, then you'd set the network mask on the ENBT module for your I/O network as 255.255.255.0. The network mask for the general plant network would be 255.255.0.0, as an example. If you for instance needed more I/O addresses you could change the I/O network mask to 255.255.254.0 (512 addresses), and assign PLC subnets to even numbers (10.x.y.z where y is always an even number). There is no "standard" as such that uses 192.168.x.x. It's just the smallest of the 3 nonroutable subnets. Thus, from the point of view of a home user, the 192.168.x.x address range is plenty and the reason that most residential grade routers default to using 192.168.x.x. From a corporate point of view, the 10.x.x.x network offers the most flexibility if you are going to run with an "isolated" and firewalled intranet so it is the most common (but not the only option). Really, there is no requirement to use these particular addresses for your intranet (since there's no direct connectioin) but standards are there to make life easier. For instance, it is much more difficult to set up a corporate internet proxy if you use routable addresses since some portion of the internet at large will be inaccessible. So from the point of view of a vendor such as Allen Bradley, the best choice to default their equipment is on the least useful nonroutable address range, or 192.168.x.y. The assumption is that for an isolated LAN, most users will just stick with 192.168.x.y. For a corporate LAN, they will get reassigned to 10.x.y.z, so when someone plugs a new device into the network, it won't cause some sort of IP address conflict while the device is being configured. A few others have special meaning: 0.0.0.1 -- null 127.0.0.x -- loopback (in practice, all 255 addresses are treated identically and most folks just use the first valid one, 127.0.0.1, RFC 1700) 169.254.x,y -- local link (for auto DHCP) 192.0.2.x -- test net (for tests only) 198.18.x.x to 198.19.x.x -- network interconnect/testing (RFC 2544) 224.x.y.z to 239.x.y.z -- multicasting (RFC 3171)