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