What Subnet do you put your PLC's on??

if there is the same IP subnet on both side of a router, not necessarily identical IPs, then routing wont work.

Exactly. Which is why we have NAT/PAT devices. There is no reason you can't have identical machines with the same IP's all on the same network separated by NAT/PAT devices.
 
If the network is standalone, not connected to any other network, and never will be connected to any other network, then use whatever you want. Public or Private, it doesn't matter.

However, that is becoming less and less common all the time as the push is to get everything connected together. Having to go back and change IP addresses for everything on your network because someone decided to use public addresses is a major PITA. Keep in mind too, that if you are using public IP addresses and you end up connecting to your corporate network where a router exists, there is a chance data will get sent to the router and forwarded to that actual IP address on the internet.

You can always stick with private, but use the less common ranges. I would suggest first that you use a range that is not being used by the corporate network. I see a lot of 10.x.x.x for corporate networks, so I would use 192.168 or 172.16 for my controls network. There are so many subnets available under those ranges that you shouldn't run into a conflict with commercial devices and their default settings.

I would absolutely not use 1.x.x.x because I think it will save me thousands of keystrokes. That is not a good reason for using a public address.

OG
 
Exactly. Which is why we have NAT/PAT devices. There is no reason you can't have identical machines with the same IP's all on the same network separated by NAT/PAT devices.

Yes but WHY go through that trouble? Just differentiate your IPs. 10.5.1.x For one system. 10.5.2.x for another, etc. all drives, PLCs, Racks, HMIs, etc in separated to their appropriate system.
 
Yes but WHY go through that trouble? Just differentiate your IPs. 10.5.1.x For one system. 10.5.2.x for another, etc. all drives, PLCs, Racks, HMIs, etc in separated to their appropriate system.
in our case, we are a machine OEM that sells standardized machines.
The IPs are not adapted to the customers network.
Parallel installed machines on the same customer site do not get unique IPs.
We use NATs for both separating machine network from customers network and separating identical parallel installed machines from each other.
A single NAT may be enough, it is a neglible cost and the least hassle. In fact it is flexible and can be adapted on the spot without the need for adapting the individual machines.
 
If you are configuring your network right there is no reason to avoid 192.168 networks. You shouldn't be just throwing devices onto a gigantic central network anyway. Not only is it asking for trouble, it makes you extremely vulnerable if an attacker gains access to the network.

One major advantage of 192.168 subnets is the ability to quickly set IP addresses for spare parts. The iTRAK system for example has a very involved process for setting IP addresses. If a customer has a spare on the shelf, they need to go through the difficult process with BootP and discovering hard to find MAC addresses... or you can just use 192.168.xxx and use the DIP switch dials on the connector and rely on autonumbering, making drop in replacements Just Work.
 
If the network is standalone, not connected to any other network, and never will be connected to any other network, then use whatever you want. Public or Private, it doesn't matter.

Also, if you don't have a tech in there connected to the machine, computer connected to his phones hot spot so he can get remote support...
 
in our case, we are a machine OEM that sells standardized machines.
The IPs are not adapted to the customers network.
Parallel installed machines on the same customer site do not get unique IPs.
We use NATs for both separating machine network from customers network and separating identical parallel installed machines from each other.
A single NAT may be enough, it is a neglible cost and the least hassle. In fact it is flexible and can be adapted on the spot without the need for adapting the individual machines.

Got ya.
 
Beer night post?

Here's what we roll with dual-IP CLX:
  • A1 interface: DHCP for customer link to PLC and CIP route to device network. Or they specify the IP.
  • A2 interface: 192.168.1.10/24, presumptive gateway 192.168.1.1 assigned to this and all devices.
As others said, the Rockwell device dials make deployment to this subnet dead easy.

On the device subnet:
  • .1 is reserved for possible gateway customer can later add.
  • .2 - 9 are reserved for any customer stuff.
  • .10: reserved for initial PLC.
  • .11: reserved for initial HMI.
  • .12 - 19 are reserved for additional PLCs and HMIs.
  • .20 - 199: reserved for devices.
  • .200 - 253: reserved for field service PCs or any other device testing.
  • .254: reserved for possible gateway.

Customer can do the following:
  • Use this as-is. PLC visibility only. In most cases, this is everything needed. Traffic automatically managed, the CIP backplane doesn't route TCP/IP traffic, so there's an insulating layer from the enterprise network.
  • Opt to have the HMI moved to the customer network for VNC, etc. Only have to update the FTLinx path to the PLC A1 interface.
  • Add their own gateway to route to the 192.168.1.0 subnet (or add their own NAT, but we try to steer them away).
  • Pay extra for a change order to a custom network and any hardware required.

Same principle for 5580:
  • Onboard interface: customer-facing.
  • 1756-ENxT bridge: 192.168.1.0/24 device subnet.

Same principle for 5570:
  • 1756-ENxT bridge: customer-facing.
  • 1756-ENxT bridge: 192.168.1.0/24 device subnet.
 
Last edited:
Interesting discussion !

One item in the PLC specification that is given vendors supplying equipment
to this facility it specifically says that 192.168.xxx.yyy is never to be used
even if behind a NAT

All IP addresses are to be assigned by the PLC department,
There are to be no duplicate addresses on the plant network except when
purchasing duplicate machines from an OEM & for them there are addition requirements.

From experience,

In over 30 years at 1 facility I program for I have only seen problems
when these rules were not followed.
(A few reasons were mentioned in my original post)

The reason I started this thread is that just last week I found ~70 IP
addresses in the 192.168.211.yyy on the public network
and was looking for other opinions.

It made it impossible to ping a PLC to see if it was alive
as you would get a reply 2 buildings away in the corporate office.

RsLinx showed disconnected.

To troubleshoot I had to disconnect from the corporate network
which means I had directly connect to the tool and that required me to driving to the facility.

Getting paid for windshield time is not my preferred way to make rent.

Hooking back to the corporate network and using 'Angry IP Scanner'
I scanned ALL 192.168.xxx.yyy addresses and found over one hundred devices.

Sorting by TTL time isolated the issue
2ms = Local PLC devices & SCADA
200ms = Computers in the Corporate office 2 buildings & 10 hops away using Traceroute

The company I was at had acquired another company a few years ago & recently started relocating their hardware.
Their IT department had built their entire corporate network using private addresses.
I am not sure how they got away with it for so long.

IT had a shoot the messenger attitude @ first but is now dealing with isolating the 192.168.xxx.yyy network behind a firewall,
but that is creating other issues because so many people use the hardware on those "Private" addresses.
 
This is the right answer because These are private subnets. This means traffic cannot be routed to them or from them to/from the internet. These ranges are a critical security layer to secure a control network.

Cannot vs Should not,
See the thread that I just posted a couple of minutes ago.

Is traffic not allowed to or from private subnets by some barrier
or just not a good idea?

As far as critical security layers 192.168.xxx.yyy are so popular
seems they would be the first targets to hack??
 
Yes, a lot of what we discuss falls under "should not".

Is traffic not allowed to or from private subnets by some barrier or just not a good idea?

This would be a router. It would determine whether traffic would be allowed to pass from one network to another.

As far as critical security layers 192.168.xxx.yyy are so popular seems they would be the first targets to hack??

If your corporate network is comprised, the address range of your control network doesn't really matter.

OG
 
I found ~70 IP
addresses in the 192.168.211.yyy on the public network
and was looking for other opinions.

Technically I believe this would be still a private network. They may have been on a different VLAN but still on the private network. It us only the ISP side of the router that is the public network.
 
Technically I believe this would be still a private network. They may have been on a different VLAN but still on the private network. It us only the ISP side of the router that is the public network.
Agree,
But they had no plan for any of the nodes to be private
It was how they built the entire corporate network from scratch
using no public addresses
 

Similar Topics

In our production plant we have multiple different networks (subnets). IT dept have setup routing between them so different subnets can...
Replies
0
Views
49
Is it possible to connect a PC with running WinCC Advanced or Unified to a siemens PLC such as S7-1200 across different subnets? The computers can...
Replies
0
Views
53
Hi. Rockwell learning curve 132-1b. I was having trouble to change IP address on a EN2TR. Finally found out that I need to change the IP...
Replies
1
Views
734
Hello everyone, I have a question... is it possible that two IPS in different network segments can see each other through communication between...
Replies
3
Views
1,061
We have two, nearly identical machines. One configuration utilizes a L33ERM and I am able to see and access the local subnet devices, such as...
Replies
8
Views
957
Back
Top Bottom