Configuring VIPAs for activation with VIPABACKUP

When adding a dynamic VIPA to a functioning sysplex, the normal order is to add VIPABACKUP statements to backup stacks, and then add a VIPADEFINE statement to the TCP/IP stack where the VIPA should normally be, at which time the VIPA would be activated and ready for use. A VIPADISTRIBUTE statement could be added at the same time, along with the VIPASMPARMS statement if the SERVICEMGR parameter is coded on the VIPADEFINE statement. The VIPA would be activated only when the VIPADEFINE was processed on the TCP/IP that would normally own it, and not when a VIPABACKUP is processed on another stack. This is, in part, because parameters on the VIPADEFINE that are needed to activate the VIPA were not found on the VIPABACKUP statement.

However, on the rare occasion that a disaster occurs, it might be necessary to IPL all of the systems in a sysplex. Assuming that many dynamic VIPAs are in use and the VIPADEFINE statements are throughout the available TCP/IP stacks in the sysplex, most of the dynamic VIPAs have a lengthy wait before the owning operating system, TCP/IP, and application are started and fully operational. The intent of dynamic VIPAs defined with VIPADEFINE and VIPABACKUP is to move the dynamic VIPAs under a functioning application as soon as possible. Therefore, optional parameters have been added to the VIPABACKUP statement to allow the dynamic VIPA to be activated when the VIPABACKUP is processed at TCP/IP initialization or VARY TCPIP,,OBEYFILE command processing. If the MOVEABLE IMMEDIATE or MOVEABLE WHENIDLE parameter is specified on a VIPABACKUP profile statement, along with required address mask and optional SERVICEMGR parameters for an IPv4 DVIPA, the dynamic VIPA will be activated when the profile statement is processed, if it is not active elsewhere in the sysplex already. The following notes apply to this case:

If the MOVEABLE parameter is specified, the address mask must also be specified. For an IPv4 DVIPA, the SERVICEMGR parameter on a VIPABACKUP statement is optional. The address mask and SERVICEMGR parameters can be specified on a VIPABACKUP statement only if the MOVEABLE parameter has also been specified.
The first started VIPABACKUP TCP/IP stack that is configured to start a particular dynamic VIPA with VIPABACKUP will activate the dynamic VIPA and own it until the VIPADEFINE stack is started. As long as the first activating VIPABACKUP stack remains operational, starting another stack with a VIPABACKUP statement will not cause the dynamic VIPA to move, even if the second stack has a higher backup rank. Only the initialization of the VIPADEFINE stack will cause the VIPA to move automatically.
When the VIPADEFINE is eventually processed, its parameters will override the values specified on the VIPABACKUP that activated the dynamic VIPA, if the VIPADEFINE has parameters that are different from those specified on the VIPABACKUP.

It is always a good idea, when able to specify a parameter on both primary and backup, to specify exactly the same values for each. When all the parameters common to VIPADEFINE and VIPABACKUP are specified the same on both for a particular DVIPA, the behavior exhibited when the VIPADEFINE stack comes up will be the same as when the DVIPA is activated first by a VIPABACKUP stack. However, for IPv4, there are several parameters that could be specified inconsistently on the VIPABACKUP and VIPADEFINE statements. If they are specified inconsistently, the following implications are some of the implications by parameter:

SERVICEMGR: If the Cisco forwarding agents are not configured to participate, then it does not matter whether SERVICEMGR is specified. If the Cisco forwarding agents are configured to participate, the following list applies if SERVICEMGR is specified differently on participating stacks:
- If SERVICEMGR is not specified on the VIPABACKUP stack, the Cisco forwarding agents will send all packets through normal IP forwarding to the stack owning the DVIPA (the VIPABACKUP stack until the VIPADEFINE stack comes up). When the VIPADEFINE stack comes up with SERVICEMGR, it will inform the forwarding agents and normal function will continue, even for existing connections. In other words, nothing fails, including existing connections, but optimal routing is not achieved unless all participating stacks code SERVICEMGR.
- If SERVICEMGR is specified on the VIPABACKUP stack, things will operate normally for MNLB integration until the VIPADEFINE stack is activated. When that happens, no new updates will be sent to the Cisco forwarding agents, meaning that existing connections will be routed optimally for a while, but all packets for new connections will be sent to the VIPADEFINE stack for routing. After the 15-minute timeout for connection routes in the forwarding agents, the existing connections will have all packets sent to the VIPADEFINE stack. Again, nothing fails, including existing connections, but optimal routing is not achieved unless all participating stacks code SERVICEMGR.
MOVEABLE: If there is any doubt, this parameter should be coded as MOVEABLE IMMEDIATE on the VIPABACKUP stack, so that the stack will maintain connection information to be sent to the VIPADEFINE stack when it comes up. Subsequent operation in the sysplex will be determined by the coding (or defaulting) of MOVEABLE on the VIPADEFINE statement, regardless of what was coded on the VIPABACKUP of the stack that first activated the DVIPA. This is true even if that same stack later takes over the DVIPA from the VIPADEFINE or another stack. (This is the reason MOVEABLE was chosen as the way to activate the new function on VIPABACKUP stacks, rather than a new keyword, to force consideration of the setting of the MOVEABLE parameter for VIPABACKUP stacks.)
address_mask: The address_mask is used to build BSDROUTINGPARMS statements. If the attached routing daemon is OMPROUTE and there is no corresponding interface definition with the subnet mask parameter in OMPROUTE configuration, OMPROUTE might send a different address mask from the VIPADEFINE stack than it will for the VIPABACKUP stack, which might confuse the routing network. The address_mask should be the same on VIPABACKUP and VIPADEFINE statements for a particular DVIPA.
Result: Incorrect OMPROUTE configuration, such as missing interface definitions for RIPv1, RIPv2, or OSPF, can lead to unexpected results, especially if OMPROUTE uses defaults for the address mask.

Assuming that dynamic VIPAs are throughout the sysplex, and that critical applications are as well, the first stack to be activated might activate most, if not all, DVIPAs, and might therefore assume a considerable amount of the workload. For any particular application, all of the workload is directed to the first stack supporting that application to be activated, regardless of what other workload will be executing on that same stack or LPAR.

Guideline: Consider the planned sysplex TCP/IP activation sequence, and have only those DVIPAs for critical applications activating on TCP/IP stacks early in the sequence, so that less important work does not interfere with the business-critical applications during sysplex startups.