Controlling the Outbound IP Address Used with a Virtual IP Address

Marc Vadeboncoeur, iTech Solutions

We recently installed a new POWER9 system at a customer site and migrated their old system to it, and the customer wanted to take advantage of multiple network switches in their data center to provide some level of network connectivity redundancy for their new system to protect against a network switch failure.

The simple solution was to use a virtual IP address implementation where we created a virtual IP TCP/IP interface that sits on top of two physical interfaces that are used to handle the network traffic (in a recent newsletter I described the exact steps on how to do this, very easy to do!).  What we did was create a virtual IP interface that was the same address as the IP address of the old system (e.g. 192.168.1.10) and two real (physical) TCP/IP interfaces (e.g. 192.168.1.11 and 192.168.1.12) that were defined to the virtual IP interface as “preferred interfaces” with each physical interface plugged into a different network switch, this is the norm for a typical virtual IP address configuration.

After the system migration was complete and the new POWER9 was live and running their business, they encountered an issue with a population of copier machines that they had been sending print output to from their IBM i environment, the output was not coming out from the new system.  An investigation into the setup on the copier machines quickly revealed that they had been configured to specifically allow straight output from only certain discrete host IPs, one of them being the host IP of their IBM i system (e.g. 192.168.1.10).  The issue was that the IBM i was reachable at the primary IP which is the virtual IP (e.g. 192.168.1.10) but the IP traffic leaving the system through one of the physical interfaces defined as preferred interfaces for the virtual IP interface was being tagged with the outbound IP address of the physical interface handling that traffic (e.g. 192.168.1.11) not the virtual IP address itself which is normal behavior.  So, those copier machines that were told to only allow straight-through print output from 192.168.1.10 were now seeing IP traffic from 192.168.1.11 and simply refusing to print.

The solution was to make a configuration change to the two physical IP interfaces used to handle network traffic for the virtual IP by specifying as “Associated local interface…” which is the keyword “LCLIFC” on the ADDTCPIFC and CHGTCPIFC commands.  When you specify the IP address of the virtual IP interface on the LCLIFC keyword for the physical IP interfaces handling the actual network traffic for that virtual IP, the system will automatically tag all the IP packets going out of that specific physical interface with the IP address of the virtual IP interface.  So, in this example, IP traffic comes into the IBM i with the 192.168.1.10 primary network address and leaves the system through the 192.168.1.11 physical interface but all traffic coming out of that interface is now tagged with the virtual IP address of 192.168.1.10 and not the IP address of the physical interface itself, so any hosts/routers/firewalls receiving the outbound IBM i traffic will be receiving that traffic from the 192.168.1.10 virtual IP address.

The screenshots below show the implementation of this scenario when creating the physical TCP/IP interfaces used to handle the virtual IP traffic.

If you are considering implementing virtual IP addressing in your IBM i environment to provide network connectivity redundancy and you have hosts on your network and/or routers/firewalls that are configured to react to traffic from a specific IBM i primary host IP address, be sure to specify an associated local interface on the physical TCP/IP interfaces used to handle your virtual IP network traffic so any IP packets leaving your system remain tagged with the primary IP address of your system.

More articles from this month:

Leave a Comment

Your email address will not be published. Required fields are marked *