Glenn Robinson shows you how to manage your TCP/IP and Ethernet connections with virtual IP addressing, the address resolution protocol and the Virtual IO Server.

Recently, I have had a number of customers asking me about Ethernet and TCP/IP resiliency features on System i. This is an interesting question as System i incorporates various operating systems. Invariably, they want to know about the resiliency features of i5/OS. A number of our customers have implemented virtual IP addressing (VIPA) which is normally the best method for implementing resiliency so let's take a look at this first.

When you add an IP interface to i5/OS, you assign it to a specific line description object which represents an Ethernet port. The built-in Ethernet adapter on the 5xx range has two ports so you need a line description for each one. A virtual IP address, however, isn't associated with a line description. Instead, it is associated with two or more IP addresses within the same subnet.

Here is an example of what I mean. You have two separate Ethernet adapters and a line description for a port on each adapter called ETHLINE1 and ETHLINE2. We assign an IP address to each of these line descriptions, 192.168.1.1 and 192.168.1.2, both with a subnet mask of 255.255.255.0. These IP addresses can be accessed as normal if required but if a user is accessing the 192.168.1.1 address and the port fails or the IP address stopped, then the clients accessing that address will stop communicating with i5/OS. To use VIPA we add a third address, 192.168.1.3, with a subnet of 255.255.255.255. Rather than assigning this address to a line description we use the value *VIRTUALIP. This IP interface then 'attaches' itself to one of the line descriptions in use by 192.168.1.1 or 192.168.1.2.

From this point on your clients should access the system by using 192.168.1.3. Now, if the port used by the 192.168.1.1 address fails, then i5/OS will automatically move the traffic over to the other physical Ethernet port.
That's the theory over. There is more to VIPA, though, and what you can do depends on the specific release of OS/400 and i5/OS you are implementing VIPA on.

ARP CONSIDERATIONS

ARP stands for address resolution protocol. This is basically a mapping between the IP address of an interface and the MAC address of the card the IP address is associated with. In our example, the 192.168.1.1 and 192.168.1.2 addresses are associated with physical Ethernet ports so there will be an association between the IP address and the MAC address stored on the clients connecting to our system and on the routers in our network. If you want to see an example of this go to a Windows command line and type in 'arp -a'. See Figure 1 as an example.

Because our 192.168.1.3 address is not associated with a line description, there won't be a MAC address associated with it but we need this to happen so that our system can be found on the network. Prior to V5R2 we cannot do this but at V5R2 and above we have the ability to do this with a function called Proxy ARP.

Proxy ARP allows a TCP/IP interface to respond on behalf of another interface, which is what we want. To enable this, we have to use iSeries Navigator. Open up iNav and select the connection to your system then navigate to Network->TCP/IP Configuration->IPv4->Interfaces. Now right-click on your VIPA interface, 192.168.1.3, and select Properties. When the dialogue box appears click the Advanced tab at the top. You will see a tick box labelled 'Enable Proxy ARP'. If your interface is active then you may not be able to set this. To do so, stop the 192.168.1.3 address and then click the tick box and press OK (see Figure 2). When the IP address is restarted, it will associate itself with one of the non-VIPA IP addresses which will act on behalf of the 192.168.1.3 address.

ASSOCIATED INTERFACES

Let's say your 192.168.1.1 interface is running at 100 Mbps but your 192.168.1.2 interface is running at 1 Gbps. Your likely preference is that you would want your VIPA to be associated with the 1 Gbps interface as this is the fastest. At V5R2 the VIPA interface will be associated with the first acceptable physical interface found. So the VIPA may be associated with the 100 Mbps interface some times and the 1 Gbps at other times. At V5R3 this changed so that the VIPA will be associated with the fastest interface. This is more like it.

These days most customers will have multiple interfaces running at 1 Gbps but you have no way of controlling the interface you would like VIPA to be associated with. V5R4 solves this by allowing you to select the interfaces to be associated with your VIPA and the order of this association. This gives you the flexibility to determine primary, secondary, tertiary interfaces etc.

You will see in Figure 2 the boxes labelled Available Interfaces and Preferred Interfaces. This is where you would specify the interfaces to use and the order of preference. You can also create a preferred interface list and assign it to the VIPA using the QTOCC4IF API. This is a fairly easy API to use in CL and example code is available in the Red Book IBM i5/OS IP Networks: Dynamic, SG24-6718-02.

FAILOVER

Now your VIPA is set up and active your clients can access the VIPA address. Should the physical interface associated with the VIPA fail, or you stop the interface, then i5/OS will automatically use the next available interface without affecting the clients.

VIRTUAL IO SERVER

A method often used by AIX and Linux partitions is via the Virtual IO Server (VIOS). This is a utility partition based on AIX which provides virtualised disk and Ethernet to other partitions. Imagine your System i, or System p, had four Ethernet adapters and you wanted to provide Ethernet adapter resilience to your LPARs. You could install VIOS into its own LPAR and have it 'own' the four Ethernet adapters. VIOS can then 'link aggregate' these adapters together to appear as one adapter. Once this is done, the link aggregation can be shared with the other LPARs on the system. This is done by creating a bridge between the physical adapters and the virtual Ethernet adapters sitting on the System i/p VLAN using a bridge.

This appears quite complex but is a great way of reducing the number of physical adapters required on an LPAR’d system while still providing Ethernet flexibility and resiliency to the resident partitions. One downside to this is that the partitions accessing the VIOS LPAR are then dependent upon it for networking capabilities. Let's say the VIOS partition fails or you need to take it down for routine maintenance, then you will loose network connectivity to your physical LAN as the VIOS server 'owns' the physical Ethenet adapters. The normal method of overcoming this is to install two VIOS partitions and have these two partition own two Ethernet adapters each, or whatever combination you wish. You could then have the other partitions configured to access both of the VIOS partitions for resilience.

One thing you will notice here is that I haven't mentioned i5/OS specifically. The VIOS server is, as mentioned, based upon AIX. Today the VIOS server can support AIX and POWER Linux for virtual storage and Ethernet but not i5/OS. It makes sense that i5/OS should also be supported by the VIOS some day soon, doesn't it?

LINKS

System i IP Networks Red Book: www.redbooks.ibm.com/redpieces/abstracts/sg246718.html
Information Center – VIPA: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzajw/rzajwviproute.htm
Virtual IO Server: http://techsupport.services.ibm.com/server/vios/home.html