Why Manufacturers duplicate IPv4 addresses and how IE switches help solve the issues

If this topic piqued your interest, you’re probably impacted by or at least curious about duplicate IP Addresses in your industrial network. You are not alone. It can be a little bewildering. There doesn’t seem to be any reason in this day and age to have duplicate IP Addresses, let alone do it on purpose. Let’s unravel the mystery.

Companies that build sophisticated machines have made the transition to Internet Protocol as the communication protocol within their machines. IPv4 is the easiest protocol to use. There are lots of software libraries in the ether based on IPv4. These companies’ core competency is the electrical and mechanical aspect of their machines, not the software that runs the machine and therefore they do not have sophisticated software teams. When you’re writing communication software and software is not your core competency, what is the easiest and least problematic way to identify the components within your machine? Answer: Static IP Addresses. The alternative to static IP Addresses is a more complicated process involving dynamic IP Address assignment, along with a complex task of identifying which IP Address the individual components received.

The IP Addresses were duplicated on purpose. The software in the machine uses static IP Addresses to identify individual machine components because it’s easier for the machine builders. Each machine they build has the same software (SW). Therefore, they use the same static IP Addresses. If you have purchased two or more of their machines, then you have duplicate IP Addresses. To be fair, it would be much harder and cost prohibitive to give each component of each machine a unique IP Address.

Figure 1: Robots represent multiple machines with identical components and software

The robots in the picture above are an example of a sophisticated machine. Each robot has the same components and the same software. Each component has its own statically assigned IP Address. This practice is not restricted to robots. Bottling machines and diaper making machines are manufactured in the same way.

Why is this a problem?

As long as you can contain the broadcasts of IPv4 Addresses of the components to stay within the machine, you should be OK. There’s always one publicly unique IPv4 address on the machine which represents the entire machine to the outside world. Again, as long as you only use this one IPv4 address to communicate with the machine, it should not present any problems. Most of the time this is how it’s done and everyone is happy.

Along comes the need to increase productivity. To increase productivity, you need more data. And where is this data? One place is inside the machine. Now you need to communicate with the components inside the machine. Once you have more than one machine, how should you communicate with the internal components that have the same IPv4 address? This is the problem.

Solutions

Before describing solutions, I’d like to uplevel the discussion to talk about Network Address Translation (NAT) in general.

Everybody should know about NAT. We use NAT every day whether we know it or not. The IPv4 router in our homes uses NAT. The IP Address assigned to your home devices (including your laptop and smartphone) is a private IP Address. This private IP Address is not routable on the Internet. Our neighbors all have in home devices with the same IPv4 addresses. It’s not a problem because our home routers use Network Address Translation (NAT) to convert private IP Addresses to a publicly routable IP Address so we can communicate with devices on the Internet. The Internet service providers use private IP Addresses for in home use because it’s easier for them. There are not enough IPv4 addresses in the world for every IP capable device to have a unique IPv4 address. And let’s face it, we have not converted to IPv6.

Your home is not the only place NAT is used. Industrial networks also need to use NAT because sophisticated machines have the same IPv4 addresses.

There are really only two ways to solve duplicate addressing problems for industrial networks. The most obvious way is to insert an additional Layer 3 device such as a firewall or router between the machine and the rest of the network—just to translate Private IP Addresses. This is similar to what you have at home. This solution requires a special network device for the purpose to convert private IPv4 addresses to publicly unique IPv4 addresses. The drawback is, that it’s an additional device to purchase and manage and, configuration and management of this Layer 3 network device can be complex, requiring someone with IT skills to setup and maintain them.

The less obvious way is to use a Cisco Industrial Ethernet (IE) switch to do the IPv4 translation. When the IE switch solves the duplicate IP addressing problem, it’s using Layer 2 NAT. Plus, in my biased opinion, configuring Layer 2 NAT on a Cisco IE switch is easier than configuring NAT on router or firewall. There’s probably an Industrial Ethernet switch in your network already connecting all the machines together. Why introduce an additional network device? Keep the same simple network architecture you have with a Cisco IE switch and solve your duplicate IPv4 addressing issues, too.

Figure 2: IE-4010 connecting multiple complex machines

In figure 2 above, each robot has the same IP Addresses for its internal components. The Cisco IE switch will translate the duplicated private IP addresses of the components of each robot (ie: complex machine) into publicly unique IP Addresses as it receives the Ethernet frames from the robots.

Sample IOS CLI configuration for the Cisco Industrial Ethernet

This is how you would configure a Cisco Industrial Ethernet switch to provide L2NAT for the first two robots on the left in Figure 2. The remaining three robots would be very similar to the first two.

You start by defining which IPv4 Addresses to translate. The Cisco IE does not know which publicly or private IP addresses you want to use. You have to tell it. You define the complete translation.

Define a translation instance for each robot. The ‘leftmost’ robot would have this translation instance for 3 of its internal components. The ‘nextleftmost’ robot would have the same private IP Addresses but unique public IP addresses.

Note: The IP Addresses for the inside hosts are the same in each of the two translation instances, and the translated public IP Addresses are unique. They have to be unique if they are to be used in the upstream network to uniquely identify the robot components.

The next step in the configuration process is to apply the translation instances to the correct interface. The ‘leftmost’ robot is connected to port Gi1/2, and the robot next to it is connected to Gi1/4.

Disclaimer: This configuration, while valid, is just an example.

When it comes to configuring anything in the IOS CLI, the example above shows how simple it can be. For those of you who do not like using the IOS CLI, the same configuration can be done using the IE’sweb based GUI.

Source: cisco.com