IPv4 considerations for OMPROUTE

The names of dynamic VIPA interfaces are assigned dynamically by the stack when a dynamic VIPA interface is created. Therefore, the Name field that is set on the Interface or OSPF_Interface statement for a dynamic VIPA is ignored by OMPROUTE.

Define an Interface or OSPF_Interface definition for every dynamic VIPA address that a host might own. Because there could be many interfaces, more wildcard capabilities are added to OMPROUTE, for dynamic VIPA interfaces only.

Ranges of dynamic VIPA interfaces can be defined by using the subnet mask parameter on the OSPF_Interface or Interface statement. The range that is defined is all the IP addresses that fall within the subnet that is defined by the mask and the IP address. The IP address parameter must be the subnet number of the range that is being defined, not a host address within that range. The following example defines a range of dynamic VIPA addresses from 10.138.165.81 to 10.138.165.94:

OSPF_Interface           
   IP_address = 10.138.165.80           
   Name = dummy_name (see tip)           
   Subnet_mask = 255.255.255.240;

Tips:

The Name parameter is required and must be unique, but it is not used for dynamic VIPAs.
When you are defining ranges, it is not necessary or desirable to code a destination address. OMPROUTE automatically sets the destination address of a dynamic VIPA to its IP address.
There is nothing in the interface definition statements that informs OMPROUTE that a particular interface definition statement is for a dynamic VIPA or a range of dynamic VIPAs. Rather, OMPROUTE learns this information from the stack when these interfaces are created or taken over.
Because dynamic VIPAs can move between z/OS® hosts, configure a router ID that specifies a physical interface or a static VIPA and not a dynamic VIPA.

OMPROUTE cannot build an advertisement with a size that exceeds the largest IP packet size, which is 64K. When this limit is reached, the following message is displayed:

EZZ7967I ADVERTISEMENT DISCARDED, OVERFLOWS BUFFER: LS
   TYPE x ID x.x.x.x ORG y.y.y.y

Result: If this limit is reached with a router link-state advertisement (LSA), OMPROUTE cannot send the router LSA and other hosts cannot calculate routes to destinations (for example, VIPAs) owned by the stack on which OMPROUTE is running. OMPROUTE ends if it encounters this condition. If OMPROUTE cannot send its router LSA, it is useless as a router.

If an LSA exceeds the maximum transmission unit (MTU) size on its network, the LSA is fragmented. This fragmentation is not a problem for OMPROUTE, but some routers cannot accept fragmented LSAs.

Tip: If you are experiencing adjacency problems with routers and have many interfaces on your stack, check for fragmentation of the OMPROUTE router LSA.

Normally, large router LSAs are not a problem, as the size of LSAs seldom exceeds 64K, or even network MTU sizes. However, if many VIPA or dynamic VIPA interfaces are defined on a host, router LSA size can become a consideration. The size of the router LSA includes 52 bytes for headers, plus the number of bytes required to advertise the interfaces that the host owns. The number of bytes required for each interface is:

VIPA: 12 bytes, plus 12 bytes for each VIPA subnet
Tip: If many VIPAs are in different subnets on the host, the size of the router LSA can be reduced by suppressing VIPA subnet routes by coding the Advertise_VIPA_Routes parameter on the OSPF_INTERFACE statement for the VIPA interfaces.
Point-to-point: 24 bytes
Point-to-multipoint: 12 bytes, plus 12 bytes for each neighbor on the interface
All other types: 12 bytes