A virtual IP address eliminates a host's dependency upon individual network interfaces. Incoming packets are sent to the system's VIPA address, but all packets travel through the real network interfaces.
Previously, if an interface failed, any connections to that interface were lost. With VIPA on your system and routing protocols within the network providing automatic reroute, recovery from failures occurs without disruption to the existing user connections that are using the virtual interface as long packets can arrive through another physical interface. Systems running VIPA are more highly available because adapter outages no longer affect active connections. Since multiple physical adapters carry the system IP traffic, overall load is not concentrated on a single adapter and associated subnet.
The AIX VIPA function is transparent to the network equipment. No special network equipment or other hardware is needed. To implement VIPA , you need to have the following:
VIPA is configured, just as any IP network interface, in SMIT. In addition, you can specify a group of interfaces while configuring VIPA. When configured this way, for all the outgoing connections initiated by the VIPA host via these interfaces, which are designated to use a VIPA, the virtual address becomes the source address placed in the TCP/IP packet header of the outgoing packets.
The following topics are covered in this section:
To add an adapter to your VIPA interface, follow these steps:
To remove an adapter from a VIPA, follow these steps:
A system has a virtual IP address, vi0, of 10.68.6.1 and two physical connections, en1 with IP address 10.68.1.1 and en5, with IP address 10.68.5.1. In this example, both physical connections are Ethernet, but any mixture of IP interfaces, such as token-ring or FDDI, would be supported as long as the subnets were ultimately attached to the larger corporate network and were known to the corporate routers.
Running the lsattr -El vi0 command produces the following results:
netaddr 10.68.6.1 N/A True state up Standard Ethernet Network Interface True netmask 255.255.255.0 Maximum IP Packet Size for This Device True netaddr6 Maximum IP Packet Size for REMOTE Networks True alias6 Internet Address True prefixlen Current Interface Status True alias4 TRAILER Link-Level Encapsulation True interface_names en1,en5 Interfaces using the Virtual Address True
Running the ifconfig vi0 command produces the following results:
vi0: flags=84000041<UP,RUNNING,64BIT>
inet 10.68.6.1 netmask 0xffffff00
iflist : en1 en5
Running the netstat -rn command produces the following results:
Routing tables Destination Gateway Flags Refs Use If PMTU Exp Groups Route Tree for Protocol Family 2 (Internet): default 10.68.1.2 UG 3 1055 en1 - - 10.68.1/24 10.68.1.1 U 0 665 en1 - - 10.68.5/24 10.68.5.1 U 0 1216 en5 - - 127/8 127.0.0.1 U 4 236 lo0 - - 10.68.6.1 127.0.0.1 UH 0 0 lo0 - -
The outgoing packets that do not have a source address set and that are routed via interfaces en1 and en5 will have the source address set to the virtual address (10.68.6.1). Incoming packets are routed to the VIPA address (10.68.6.1) advertised on the network. Because vi0 is virtual -- not associated with any device -- there should be no entries for it in the system-wide routing table displayed via the netstat -rn command. This means no interface route is added when the interface is configured in SMIT.
If one of the physical interfaces, a network attachment, or a network path fails, the network protocols route to the other physical interface on the same system. If a remote system telnets to the vi0 address, packets to vi0 can arrive using either en1 or en5. If en1 is down, for example, packets can still arrive on en5. Note that routing protocols might take time to propagate the routes.
When using the VIPA, the end systems and intervening routers must be able to route the packets destined for VIPA (vi0) to one of the physical interfaces (en1 or en5).
The VIPA concept is similar to IP aliases except that the addresses are not associated with a hardware interface. VIPA offers several advantages that IP aliases does not:
Individual interfaces are still accessible to other systems after VIPA is implemented. However, using the real IP addresses for ping and telnet sessions sidesteps the VIPA advantage of communicating independent of the physical adapters. VIPA hides physical adapter failures from the outlying clients. Using the real addresses reintroduces the dependency upon the physical adapters.
If the remote system contacts the VIPA system using the VIPA address or if an application on the VIPA system initiates the communication to another system, the VIPA address will be used as the source IP address in the packet. However, if the remote system initiates the session using the IP address of the real interface, that real IP address will be the source IP address in the responding packets. There is one exception. For applications that bind to a particular IP interface, the outgoing packets will carry the source address of the interface to which they are bound.
The gated daemon was modified for VIPA so that it would not add the interface route or send advertisements over virtual interfaces. The OSPF protocol, supported by gated, will advertise the virtual interface to neighboring routers. The other hosts on the network will be able to talk to the VIPA host through the first-hop router.
Multiple virtual interfaces may be configured.
Multiple VIPA interfaces would be useful, for example, if network routers could give preferential treatment to packets sent to or from certain VIPA addresses. Or, you might use multiple VIPA interfaces if they were binding applications to a specific VIPA interface. For example, to run multiple web servers for multiple companies on a single machine, you could configure the following:
It was also not possible to specify a group of interfaces that use a particular VIPA in AIX 5.1. The first VIPA in the address list would get chosen as the default source address when the application does not explicitly bind to an address.