IP Address Standards

What's your opinion about standard IP addresses for the PLC, remote I/O, machines, etc., etc. on an "integrated" line? When certain companies don't have their own protocol we must use, I'd like to suggest logical IP addresses while not easily conflicting with a few existing devices/machines (small companies).

Example:
Connecting 5 to 10 devices/machines together.

PLC - MACHINE A) 170.170.170.20
PLC - MACHINE B) 170.170.170.30
PLC - MACHINE C) 170.170.170.40
PLC - MACHINE D) 170.170.170.50
REMOTE I/O UNIT E) 170.170.170.60
REMOTE I/O UNIT F) 170.170.170.70
REMOTE I/O UNIT G) 170.170.170.80

What's a good standard first half (170.170.170.XXX)???
What's a good standard increment? (leave 1-19 spare, skip ahead by 10 in case a device/machine gets added between two in the future)???

Thanks!

For a start, I'd suggest using one of the Private IP addresses.

Private Ranges:
10.0.0.0 -> 10.255.255.255
172.16.0.0 -> 172.31.255.255
192.168.0.0 -> 192.168.255.255

Historically, I've seen many "smaller" organizations use the 192.168 range, so I'd probably avoid one of those. If the network will never need access to the outside world, the selection is most likely moot. Many years ago at my place of employment we had the joyous task of readdressing our entire network once we became connected to the internet. The address scheme that our folks had used was not a private address. (It happened to be the example address from our admins training manual.)

Currently our setup is as follows: (We are probably a bit more involved than most.)
For our PLCs we use a 10.x.x.0-254 address.
HMIs use a 10.x.Y.0-254 address.
We require a second network connection for our Remote I/O.
Addressing of our Remote I/O uses a 192.168.x.0-254 range. We try to match the last octet of the PLCs main network address to the third octet in the RIO range. For example: The "Main Network" address for a PLC is 10.1.1.101, the RIO address would then be 192.168.101.x.

Within a single network, we tend to follow...
192.168.1.1-89 - Network Hardware/Servers/Access Points
192.168.1.90-99 - Available DHCP Addresses
192.168.1.100-199 - PLCs
192.168.1.200-254 - HMIs

We only tend to gap device types, not devices.
For Example:
Main Router = 192.168.1.1 (Gateway For Network-Normally configured on others even if not used initially for routing.)
Main Server = 192.168.1.10
Wireless Access Point 1 = 192.168.1.20
Wireless Access Point 2 = 192.168.1.21

PLC 1 = 192.168.1.100
PLC 2 = 192.168.1.101

HMI 1 = 192.168.1.200
HMI 2 = 192.168.1.201

Richard

Hi Richard,

Your method is similar to how I do it, main difference is that with Ethernet based IO (Modbus TCP, Profinet and Ethernet I/P) now in common use, a method is needed to account for that. Do you just use the PLC range for that?

I take a line and make a a network for plc's and IO and another for drives and another for HMI's and another for misc things. Expand the amount of networks by changing the mask. this is setup for 4 networks which is in most cases more expansion than you will ever need IMHO.

Line # 1

Networks

10.1.0.0-255/22
10.1.1.0-255/22
10.1.2.0-255/22
10.1.3.0-255/22

Mask

255.255.252.0


Line # 2

Networks

10.2.0.0-255/22
10.2.1.0-255/22
10.2.2.0-255/22
10.2.3.0-255/22

Mask

255.255.252.0

Line # 3

Networks

10.3.0.0-255/22
10.3.1.0-255/22
10.3.2.0-255/22
10.3.3.0-255/22

Mask

255.255.252.0

I like PLCKid's approach in terms of easy expandability. You just need to keep your size and future size in mind when coming up with this. His approach gives you 64K nodes on each "line", with the potential for 255 lines. The consistent numbering makes it easy to predict what the address will be. One potential downside of such overallocation is that it would be a mess if you wanted to internally route traffic to another site that uses overlapping address ranges. You'd most likely have to do a giant re-addressing or not have the option. This isn't common, though, because this whole scheme pretty much implies that you aren't accessing it from the outside.

Def use a private range from Richard's suggestion.

@Richardwall - (This is hacky) IT could have configured network address translation (NAT) in a way that your router hides your network addresses just like a home router. This precludes the option for "real" Internet computers to initiate inbound connections except specific, statically mapped ones. In that situation, coming up with a good IP scheme and doing the migration.

surferb

Much of this can be accessed from outside and our sister plants but it is all over vpn. Most of the vpn links are in the 192.168.50.0-255 range and traffic is routed to and from each line depending on the login credentials of the vpn link.

Example if I login to do remote programming changes then when I use SSL VPN I am given a IP address from the DHCP pool from 192.168.100.0-100 which is for remote programming and with my login credentials I have a firewall rule of allow all with these credentials to all lines and all nodes on each line.

With remote access and data logging and reporting to corporate and sister plants I am nearing 700 firewall rules which is nothing for the firewall we have.

Also the AD login credentials follow through to my FT Asset Centre Server which allow read only and read /write to all or specific subroutines in plc programs and HMI's depending on credentials also.

Bubba has read only in the facility and has no remote access.

I try to avoid using a less restrictive mask than /24 to cut down on broadcast traffic. We've portioned systems into /27 mostly. Larger systems get /26 or /25. If needed, we use static routes to connect system to system.

I keep everything on 10.x.y.z, where x is the plant number, y is the cost center, and z's are the machine PLC's and HMI's. Single subnet (for each plant) of 255.255.0.0 (or 10.x.0.0/16 if you prefer). There is a single VPN access point to each plant, and even with everything living on essentially the same network (per site), we have no bandwidth issues, mostly due to intelligent switches all over the place.

@Doug - As far as I/O is concerned, we tend to keep I/O on a dedicated RIO network for each applicable system. If it is not cost effective to run lines for each RIO, we have gone the route of adding another VLAN for the entire system. Main goal was to limit traffic on the "main" PLC network.

@surferb - This was in the early 90's, prior to mass NAT usage. We actually obtained our own Class C in `93. I still remember when Mosaic came out.

Richard

we use IP addresses in numerical order in groups of 5(xxx.xxx.xxx.1-5, then xxx.xxx.xxx.6-10) We set up the PLC, HMI, Swtich, a MOXA, and IP radio in that order( xxx.xxx.xxx.1 and xxx.xxx.xxx.6 would be PLCs)

Thanks for the all the replies.

I don't know enough about masking to get into that, but the "private ranges" are interesting. I'll stick to something in that range and it should be a good enough default. Thanks again.

Google RFC 1918 for more info.