Steps for configuring OSPF and RIP (IPv4 and IPv6)

RIP uses a distance vector algorithm to calculate the best path to a destination based on the number of hops in the path. OSPF uses a link state or shortest path first algorithm.

Perform the following steps to configure OSPF and RIP (IPv4 and IPv6):

1. Set the global configuration options. Use the GLOBAL_OPTIONS statement to set the Ignore_Undefined_Interfaces parameter for OMPROUTE processing. Undefined interfaces are stack interfaces that are not configured by using OMPROUTE interface definitions, either explicit definitions or wildcard definitions. If you specify the value YES on the Ignore_Undefined_Interfaces parameter (Ignore_Undefined_Interfaces=YES), OMPROUTE does not configure undefined interfaces with default values. When Ignore_Undefined_Interfaces is set to the value NO, OMPROUTE configures undefined interfaces with default values that can override the stack definition values. The default value for Ignore_Undefined_Interfaces is NO.
   Tip: Specify Ignore_Undefined_Interfaces=YES to ensure that undefined interfaces are not configured with default values that might affect network connectivity.
2. Set the OSPF router ID, if the OSPF protocol is used. Every router in an OSPF autonomous system must be assigned a unique router ID.
   • IPv4 OSPF

     Code the ROUTERID parameter of the OSPF configuration statement within the OMPROUTE configuration file to assign the router ID. The value must be the IP address of one of the OSPF_INTERFACEs defined in the OMPROUTE configuration file. If the ROUTERID parameter of the OSPF configuration statement is not coded, OMPROUTE chooses the IP address from one of the OSPF_INTERFACE statements as the router ID. Because dynamic VIPAs (DVIPAs) can move between z/OS® hosts within a sysplex, the router ID should be the IP address of a physical interface or a static VIPA, but not a dynamic VIPA. For more information about the rules and guidelines for the ROUTERID parameter of the OSPF statement, see z/OS Communications Server: IP Configuration Reference.

     In the example network that is shown in Figure 1, the router ID is set to the static VIPA address that represents each OMPROUTE router. TCPCS4 has ROUTERID=4.4.4.4, and TCPCS7 has ROUTERID=7.7.7.7.

   • IPv6 OSPF

     The ROUTERID parameter of the IPV6_OSPF configuration statement is coded within the OMPROUTE configuration file to assign the IPv6 OSPF router ID. This router ID is any IPv4-style dotted decimal value except for 0.0.0.0, with care taken to assure its uniqueness across routers within the IPv6 autonomous system. If the ROUTERID parameter of the IPV6_OSPF configuration statement is not coded and the IPv4 OSPF protocol is also being used, OMPROUTE uses the IPv4 OSPF router ID as the IPv6 OSPF router ID. If the IPv4 OSPF protocol is not being used, the ROUTERID parameter of the IPV6_OSPF statement must be specified. For more information about the rules and guidelines for the ROUTERID parameter of the IPV6_OSPF statement, see z/OS Communications Server: IP Configuration Reference.

     In the example network that is shown in Figure 2, the ROUTERID parameter of the IPV6_OSPF statement on TCPCS64 is to be explicitly configured by using ROUTERID=64.64.64.64.

3. Define OSPF areas, if the OSPF protocol is used. The sample network that is shown in Figure 1 and Figure 2 depicts an IPv4 network and an IPv6 network, both divided by using two methods. The first division is between IP subnetworks within the OSPF autonomous system (AS) and IP subnetworks external to the OSPF AS (within the RIP AS). The subnetworks included within each OSPF AS are further subdivided into regions called areas. OSPF areas are collections of contiguous IP subnetworks. The function of areas is to reduce the OSPF overhead that is required to compute routes to destinations in different areas. Overhead is reduced because less information is exchanged and stored by routers and because fewer processor cycles are required for a less complex route table calculation.

   Every OSPF AS with multiple areas must have at least a backbone area. The backbone is always identified by area number 0.0.0.0. For networks with multiple areas, the backbone provides a core that connects the areas. Unlike other areas, the backbone subnets can be physically separate. In this case, logical connectivity of the backbone is maintained by configuring virtual links between backbone routers across intervening non-backbone areas. For more information, see step 8.

   Routers that attach to more than one area function as area border routers. All area border routers are part of the backbone, so they must either attach directly to a backbone IP subnet or be connected to another backbone router over a virtual link.

   The information and algorithms that are used by OSPF to calculate routes vary according to whether the destination is within the same area, in a different area within the OSPF AS, or external to the OSPF AS. Every router maintains a database of all links within its area. A shortest path first algorithm is used to calculate the best routes to destinations within the area from this database. Routes between areas are calculated from summary advertisements that are originated by area border routers for destinations that are located in other areas of the OSPF AS. External routes (for example, routes to destinations that lie within a RIP AS) are calculated from AS external advertisements that are originated by AS boundary routers and flooded throughout the OSPF AS.

   • IPv4 OSPF
     Use the AREA configuration statement to define the areas to which a router attaches. If you do not use the AREA statement, the default is that all OSPF interfaces attach to the backbone area. In the sample network, TCPCS4 and TCPCS7 are both area border routers that belong to both the backbone area (0.0.0.0) and area 1.1.1.1.

     AREA
       Area_Number=0.0.0.0;
     
     AREA
       Area_Number=1.1.1.1;

   • IPv6 OSPF

     Use the IPV6_AREA configuration statement to define the areas to which a router attaches. If you do not use the IPV6_AREA statement, the default is that all IPv6 OSPF interfaces attach to the backbone area. In the sample network, TCPCS64 and TCPCS67 are area border routers that belong to both the backbone area (0.0.0.0) and area 6.6.6.6.

     IPV6_AREA
        Area_Number=0.0.0.0;
     IPV6_AREA
        Area_Number=6.6.6.6;

4. Limit information exchange between OSPF areas, if the OSPF protocol is used. When area border routers are configured, the OSPF route information that crosses the area boundary can be controlled with configuration statements. For information about the usefulness of multiple areas in the z/OS CS environment, see Minimizing the routing responsibility of z/OS Communications Server.

   One option is to define an area as a stub area. AS external advertisements are never flooded into stub areas. In addition, the origination into the stub area of summary advertisements for interarea routes can be suppressed, creating what is commonly known as a totally stubby area.

   Destinations external to the stub area are still reachable since the area border routers advertise default routes into stub areas. Traffic within the stub area for unknown destinations is forwarded to the area border router (by using the default route). It is acceptable for routers within the area to use a default route for traffic that is destined outside the AS. The border router uses its more complete routing information to forward the traffic on an appropriate path toward its destination.

   The following requirements must be met for an area to be defined as a stub area:

   • No virtual links are configured through the area to maintain backbone connectivity.
   • No routers within the area are AS boundary routers (OSPF routers that advertise routes from external sources as AS external advertisements).
     Tip: Static routes and RIP routes are AS external.

   Another option is to use IP address ranges to limit the number of summary advertisements that are originated out of an area. In IPv4, a range is defined by an IP address and an address mask. Destinations are considered to fall within the range when the destination address and the range IP address match after the range mask is applied to both addresses. In IPv6, a range is defined by an IP address prefix and a prefix length, and destinations are considered to fall within the range if a destination address and a range IP address match for the length of the range prefix.

   When a range is configured for an area at an area border router, the border router suppresses summary advertisements for destinations within that area that fall within the range. The suppressed advertisements would have been originated into the other areas to which the border router attaches. Instead, the area border router originates a single summary advertisement for the range or no advertisement at all, depending on the option that is chosen with the configuration statement.

   Rules:

   1. If the range is not advertised, there will be no interarea routes for any destination that falls within the range.
   2. Ranges cannot be used for areas through which virtual links are configured to maintain backbone connectivity.
   • IPv4 OSPF

     The following statement configures an OSPF area as a stub area. The Import_Summaries=No parameter results in the suppression of summary advertisements for interarea routes into the stub area, creating a totally stubby area:

     AREA
       Area_Number=2.2.2.2
       Stub_area=Yes
       Import_Summaries=No;

     In the sample network that is shown in Figure 1, the following RANGE statement could be configured on TCPCS7 to prevent TCPCS7 from advertising destinations in the 9.67.101.0 subnet into the backbone area (Area 0.0.0.0):

     RANGE
        IP_Address=9.67.101.0
        Subnet_Mask=255.255.255.0
        Area_Number=1.1.1.1
        Advertise=No;

   • IPv6 OSPF

     The following statement configures an IPv6 OSPF area as a stub area. The Import_Summaries=No parameter results in the suppression of summary advertisements for interarea routes into the stub area, creating a totally stubby area:

     IPV6_AREA
        Area_Number=1.1.1.1
        Stub_area=Yes
        Import_Prefixes=No;

     In the sample network, the following IPV6_RANGE statement could be configured on TCPCS67 to cause TCPCS67 to advertise all destinations in the 2001:0DB8:0:31::/64 prefix into the backbone area (Area 0.0.0.0) as a single route to the 2001:0DB8:0:31::/64 prefix:

     IPV6_RANGE
        Prefix=2001:0DB8:0:31::/64
        Area_Number=6.6.6.6
        Advertise=Yes;

5. Define IPv4 interfaces, if the IPv4 OSPF or IPv4 RIP protocol is used. Define each interface in use by the stack to OMPROUTE by using an OSPF_INTERFACE, RIP_INTERFACE, or INTERFACE statement. This topic describes the differences between interface types for your consideration when you are configuring interfaces to OMPROUTE. In general, use the following guidelines:
   • An interface over which the OSPF protocol is communicated with other routers must be configured with the OSPF_INTERFACE statement.
   • An interface over which the RIP protocol is communicated with other routers must be configured with the RIP_INTERFACE statement.
   • Either configure all other interfaces with the INTERFACE statement, or configure OMPROUTE to ignore undefined interfaces by using the IGNORE_UNDEFINED_INTERFACES parameter of the GLOBAL_OPTIONS statement in the OMPROUTE configuration file. It is important that one or the other is done.

     If OMPROUTE is not configured to ignore undefined interfaces, it configures stack interfaces that are not defined to OMPROUTE with default values. These values might not be desirable. For example, the class mask is used as the subnet mask and 576 is used as the MTU value. Furthermore, OMPROUTE overrides stack values with its default values. To prevent this situation from happening, either configure every interface, even those interfaces that are not using RIP or OSPF, or configure OMPROUTE to ignore undefined interfaces.

   A VIPA interface is an exception to these guidelines and is described in more detail in this step.

   z/OS Communications Server enforces RFC rules against using either a subnetwork broadcast or network address as a host address. (An address that has all ones in the host portion is a subnet broadcast address. An address that has all zeros in the host portion is the subnet network address.) Therefore, the subnet_mask on an OSPF_INTERFACE, RIP_INTERFACE, or INTERFACE statement should have enough zero bits such that no home address in that subnet has all zeros or all ones in the host portion of the address. For example, if a subnet has two home addresses 10.1.1.1 and 10.1.1.2, the subnet mask must have zeros in at least 2 bits; for example, 255.255.255.252. However, if a subnet has four home addresses 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4, the subnet mask must have zeros in at least 3 bits; for example, 255.255.255.248. In this case, there can be up to six home addresses in that subnet (10.1.1.1 through 10.1.1.6). In general, if a subnet mask has n zero bits, then there can be up to ((2**n)-2) home addresses in that subnet. This limit applies even if the home addresses are configured on different TCP/IP stacks.

   Rules:

   1. OMPROUTE supports a maximum of 255 real, physical, IPv4 interfaces (that is, interfaces on which data can actually be sent and received). There is no theoretical limit on how many VIPAs can be configured, though there are practical limits that are imposed by network design.
   2. RIP version 1 uses broadcast and RIP version 2 uses multicast. RIP version 1 cannot run on a medium that supports multicast but not broadcast, which is the default QDIO configuration. To configure the OSA-Express feature operating in QDIO mode (for example, gigabit Ethernet) to send and receive broadcast packets, use the IPBCAST parameter on the LINK statement in your TCP/IP profile. The OSA-Express microcode level must support broadcast to use this parameter. Some levels of OSA-Express microcode support multicasting but not broadcasting. In this case, RIP version 2, which relies on multicast, is preferred over RIP version 1, which relies on broadcast.
   • Configuring multi-access parallel interfaces

     Whenever configuring multi-access parallel interfaces (primary and backup redundant interfaces with IP addresses in the same network) for OMPROUTE (OSPF), use the Parallel_OSPF parameter on the OSPF_INTERFACE statement to designate whether each OSPF interface is primary or backup. If the IP_address parameter on an OSPF_INTERFACE statement is using wildcards (*), also include the Name parameter for the interface to distinguish the primary from the backups. For more information about the OSPF_INTERFACE statement and its parameters, see z/OS Communications Server: IP Configuration Reference.

   • Point-to-point (For example, CTC and CLAW)

     For point-to-point interfaces, the destination IP address must be known to OMPROUTE. If OSPF or RIP is run on the interface, the destination IP address is learned when the router at the other end comes up and shares information with OMPROUTE. Additionally, defining a destination address on an interface that is running OSPF or RIP allows OMPROUTE to learn and advertise a route to that destination address before a neighboring router becomes fully adjacent. This can be beneficial if the neighboring router takes a long time to come up, or is otherwise not expected to be promptly and reliably available.

     Tip: For a point-to-point interface that is running OSPF, OMPROUTE does not advertise a host route to its own home address on the point-to-point interface. By default, OMPROUTE advertises a host route to the link destination, and relies on the router at the other end to advertise a host route to the OMPROUTE home address. This behavior is described by the OSPF architecture, RFC 1583 (OSPF version 2), section 12.4.1. This means that the OMPROUTE home address on the point-to-point link cannot be advertised as reachable unless there is a neighboring router available to advertise it. OMPROUTE implements an extension that is described in RFC 2328 to overcome this limitation. If a neighboring router will not be reliably available over the point-to-point link, you might want to code the parameter SUBNET=YES on the OSPF_INTERFACE statement for the point-to-point interface. This parameter causes OMPROUTE to implement option 2 described in RFC 2328, section 12.4.1.1, and advertise a route to the point-to-point link subnet address, which makes both endpoints reachable regardless of the status of a neighboring router.

     If the interface is only an INTERFACE (not running OSPF or RIP), specify the DESTINATION_ADDR parameter to allow for the creation of a host route to the address at the remote end of the interface.

     Sample OSPF_INTERFACE:

     OSPF_INTERFACE
     	IP_Address=9.67.106.7
     	Name=CTC7TO4
     	Subnet_mask=255.255.255.0
     	Attaches_to_Area=1.1.1.1
     	Destination_Addr=9.67.106.4;

     Sample RIP_INTERFACE:

     RIP_INTERFACE
     	IP_Address=9.67.103.7
     	Name= CTC7TO6
     	Subnet_mask=255.255.255.0
     	Destination_Addr=9.67.103.6
     	RIPV2=Yes;

     Sample INTERFACE:

     INTERFACE
     	IP_Address=9.67.111.1
     	Name=CTCX
     	Subnet_mask=255.255.255.0
     	Destination_addr=9.67.111.2;

     Note: If another router is directly attached through a CLAW device, and the OSPF protocol is being communicated with that router, the other router must also be configured to view the CLAW device as a point-to-point interface. Failure to do this results in a failure to add any routes through that router.
   • Point-to-multipoint

     For point-to-multipoint capable interfaces (for example MPCPTP interfaces including XCF and IUTSAMEH connections), OMPROUTE must know the IP addresses of the other routers (neighbors) with which it must communicate the OSPF or RIP packets. However, because of underlying signaling that takes place when a host connects to these network types, the stack is able to learn the required addresses. In turn, OMPROUTE learns those IP addresses from the stack. As a result, it is not necessary to configure the IP addresses of the other routers on the interface statements.

     Sample OSPF_INTERFACE:

     OSPF_INTERFACE	
     	IP_Address=9.27.13.81
     	Name=XCFD00	
        Attaches_to_Area=1.1.1.1
     	Subnet_mask=255.255.255.0;

     Sample RIP_INTERFACE:

     RIP_INTERFACE
     	IP_Address=9.27.23.81
     	Name=MPCA01
     	Subnet_mask=255.255.255.0
     	RIPV2=Yes;

     Sample INTERFACE:

     INTERFACE
     	IP_Address=9.27.33.81
     	Name=XCFB00
     	Subnet_mask=255.255.255.0;

   • Non-broadcast network interfaces (For example, Hyperchannel and ATM)
     If the OSPF or RIP protocol communicates with one or more routers over a non-broadcast network interface, OMPROUTE must know the IP addresses of the other routers (neighbors) with which it must communicate. For non-broadcast network interfaces, there is no underlying signaling that allows the stack to learn the required IP addresses. As a result, the neighbor addresses must be configured to OMPROUTE with the parameters configured as follows:

     • DR_NEIGHBOR parameter, NO_DR_NEIGHBOR parameter, or both on the OSPF_INTERFACE statement
     • NEIGHBOR parameter on the RIP_INTERFACE statement
     • NON_BROADCAST=YES and ROUTER_PRIORITY parameters on the OSPF_INTERFACE statement

     In the OSPF case, DR_NEIGHBOR defines which routers within the non-broadcast network can become the designated router. NO_DR_NEIGHBOR defines which routers cannot become the designated router. ROUTER_PRIORITY defines the priority of this router on the non-broadcast network so that the designated router can be elected for the network. Multiple DR_NEIGHBOR and NO_DR_NEIGHBOR parameters can be coded on one statement.

     Sample OSPF_INTERFACE:

     OSPF_INTERFACE	
     	IP_Address=9.37.84.49
     	Name=HCHE00
     	Subnet_mask=255.255.255.0
        Attaches_to_Area=1.1.1.1
     	Non_Broadcast=Yes
     	DR_Neighbor=9.37.84.53
     	No_DR_Neighbor=9.37.84.63
     	Cost0=3
     	Router_Priority=2;

     Sample RIP_INTERFACE:

     RIP_INTERFACE
     	IP_Address=9.37.104.79
     	Name=ATME00
     	Subnet_mask=255.255.255.0
     	RIPV2=Yes
     	Neighbor=9.37.104.85
     	Neighbor=9.37.104.53;

     Sample INTERFACE:

     INTERFACE
     	IP_Address=9.77.13.49
     	Name=ATMB00
     	Subnet_mask=255.255.255.0;

   • Broadcast network interfaces (For example, Ethernet)

     When the OSPF or RIP protocol is communicated over a broadcast medium such as Ethernet, these networks allow for broadcasting and multicasting. Therefore, it is not necessary for OMPROUTE to know the IP addresses of the other routers on the network for OSPF or RIP packets to be communicated with those routers. OMPROUTE sends packets to the other routers on the network by using appropriate broadcast or multicast addresses. The IP addresses of the other routers are learned as OSPF/RIP packets are received from them. The OSPF_INTERFACE must include the ROUTER_PRIORITY parameter to help elect a designated router for the network.

     Sample OSPF_INTERFACE:

     OSPF_INTERFACE	
     	IP_Address=9.59.101.5
     	Name=TR1	
        Subnet_mask=255.255.255.0
     	Attaches_to_Area=1.1.1.1
     	Cost0=2
     	Router_Priority=1;

     Sample RIP_INTERFACE:

     RIP_INTERFACE
     	IP_Address=9.29.107.3
     	Name=TR2
     	Subnet_mask=255.255.255.0
     	RIPV2=Yes;

     Sample INTERFACE:

     INTERFACE
     	IP_Address=9.77.14.49
     	Name=ETHB00
     	Subnet_mask=255.255.255.0;

     If OMPROUTE is to communicate with the OSPF or RIP Version 2 protocol over a token ring media where an attached router does not listen for multicast MAC address 0xC000.0004.0000, see Token-ring multicast.

     For interfaces into broadcast media which contain routers that do not support multicast, it is possible to configure the interfaces as non-broadcast network interfaces, which would cause OMPROUTE to unicast to the neighbor addresses rather than using a multicast address. However, it would also be necessary to configure all the routers on the network to unicast. Otherwise, their multicast packets would never be received.

     Note that it is possible to define neighbors by using DR_NEIGHBOR and/or NO_DR_NEIGHBOR parameters for OSPF_INTERFACEs and by using NEIGHBOR parameters for RIP_INTERFACEs that are broadcast capable, but it is not required or advised. If you define neighbors on these interfaces, you must define all of them, as OMPROUTE does not communicate RIP or OSPF to undefined neighbors if any are defined on an interface.

   • VIPA interfaces (Static VIPA and Dynamic VIPA)

     If only the RIP protocol is used by OMPROUTE, define VIPA interfaces with the INTERFACE statement. If only OSPF or if both OSPF and RIP are used by OMPROUTE, define VIPA interfaces with the OSPF_INTERFACE statement.

     Sample OSPF_INTERFACE:

     OSPF example:
     	OSPF_INTERFACE	
     	IP_Address=4.4.4.4
     	Name=VIPA1
        Subnet_mask=255.255.255.252;

     Sample INTERFACE:

     non-OSPF example:
     	INTERFACE
     	IP_Address=6.6.6.6
     	Name=VIPA1
     	Subnet_mask=255.255.255.252;

     Rule: The most specific subnet mask you can specify is 255.255.255.252.
     If the name in an OSPF_INTERFACE or INTERFACE statement refers to a link of type VIRTUAL, then OMPROUTE generates and advertises the following routes whenever applicable:

     • A network route to the network specified in that statement
     • A subnet route to the subnet specified in that statement
     • A host route to the IP_address specified in that statement

     The following conditions apply for advertising these routes on a physical network interface to a network:

     • Network route - if VIPA is not in the same network as the physical network interface and is allowed by filters or RANGE.
     • Subnet route - VIPA subnet routes are advertised in OMPROUTE in all conditions, except for RIP when filters prevent it.
     • Host route - as allowed by filters or RANGE. Advertisement of the host route for a VIPA defined on an OSPF_INTERFACE statement can be controlled by the SUBNET parameter on the OSPF_INTERFACE statement that defines that VIPA. If SUBNET=YES, then the host route is not advertised. If SUBNET=NO (the default), the host route is advertised. Take care in using this parameter. Do not suppress VIPA host routes for dynamic VIPAs or for VIPAs whose subnet might exist on multiple hosts. It is up to the user to ensure that these restrictions are enforced, as they are not and cannot be enforced by OMPROUTE.
     On the RIP_INTERFACE statement for a physical network interface, the VIPA routes are allowed to be advertised by the following filter parameters:

     • Send_Net_Routes
     • Send_Subnet_Routes
     • Send_Host_Routes, and Send_Only

     In addition, the global FILTER and Send_Only statements for RIP can be used to specify which routes are advertised or not.

     For OSPF, the RANGE statement can be used to advertise or not to advertise the VIPA routes external to an area in terms of address range based on a subnet mask.

     Note: For RIP, the Send_Only = (VIRTUAL) filter with the Send_Net_Routes, Send_Subnet_Routes, and Send_Host_Routes filters, or the FILTER statement with VIPA routes, indicates whether VIPA routes can be advertised over a RIP interface. Unlike RIP, there are no routing filters for OSPF. For OSPF, the RANGE statement can be used to control which address range of routes can be advertised or not advertised external to an area; however, it is not granular enough for use as a routing filter. In area-border router configurations, if there are multiple VIPA addresses that are uniquely subnetted, the RANGE statement can be used to specify which VIPA subnet address range of routes can be advertised or not advertised external to an area.

     For Dynamic VIPA (DVIPA), link names are assigned programmatically by the stack when the DVIPA is created. Therefore, the name field that is set on the INTERFACE or OSPF_INTERFACE statement is ignored by OMPROUTE for DVIPAs.

     Because a stack can have many DVIPAs defined, and DVIPA ranges, more wildcard capabilities exist on the OSPF_INTERFACE and INTERFACE statements for use only with DVIPAs.

     Ranges of DVIPA interfaces can be defined by using the Subnet_Mask parameter on the OSPF_INTERFACE or INTERFACE statement. The range that is defined in this way includes 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. Further information about the Subnet_Mask parameter is available earlier in this step.

     In the following example, DVIPA interfaces in the range of 10.138.65.81 through 10.138.65.94 are defined:

     Sample OSPF_INTERFACE:

     OSPF example:
     	OSPF_INTERFACE	
     	IP_Address=10.138.65.80
     	Name=DVIPAs
        Subnet_mask=255.255.255.240;

     Sample INTERFACE:

     non-OSPF example:
     	INTERFACE
     	IP_Address=10.138.65.80
     	Name=DVIPAs
     	Subnet_mask=255.255.255.240;

     In the following example, only an interface with home address 10.138.65.98 is being defined, because the subnet number (obtained by using a binary file AND operation of the IP_Address parameter and the Subnet_mask parameter) for this definition is 10.138.65.96. Because the IP_Address parameter does not equal that subnet number, this definition cannot be treated as a DVIPA wildcard.

     OSPF_INTERFACE
     IP_Address=10.138.65.98
     Name=DVIPA
     Subnet_mask = 255.255.255.240;

     In the following example, DVIPAs with IP addresses 10.138.120.x and 10.138.121.x with a 24-bit mask (255.255.255.0) result in two subnets 10.138.120.0/24 and 10.138.121.0/24. The 10.138.120.0/24 subnet ranges from 10.138.120.1 through 10.138.120.254 and the 10.138.121.0/24 subnet ranges from 10.138.121.1 through 10.138.121.254. Two OSPF_INTERFACE statements with the extended wildcard capabilities are defined.

     

     OSPF_INTERFACE
        IP_Address=10.138.120.0  
        Name=DVIPAs                 
        Subnet_mask=255.255.255.0;

     

     OSPF_INTERFACE
        IP_Address=10.138.121.0     
        Name=DVIPAs                 
        Subnet_mask=255.255.255.0;

     

     In the following example, DVIPAs with IP addresses 10.138.120.x and 10.138.121.x with a 23-bit mask (255.255.254.0) result in a collapsed subnet 10.138.120.0/23. The 10.138.120.0/23 subnet ranges from 10.138.120.1 through 10.138.121.254.

     

     OSPF_INTERFACE
        IP_Address=10.138.120.0     
        Name=DVIPAs                 
        Subnet_mask=255.255.254.0;

     
     Note:

     • If the conventional wildcard IP_Address=10.138.120.* is coded, OMPROUTE does not match the 10.138.121.x addresses for the DVIPAs because the subnet mask is not taken into account. Therefore, these DVIPAs might not be added to the OSPF domain.
     • If DVIPAs across multiple networks are collapsed into one supernet, the same principle with the mask applies to the extended wildcard capability. For example, a supernet address 192.168.100.0 with a 23-bit mask (255.255.254.0) covers the of range 192.168.100.1 through 192.168.101.254.

     
     You must consider an additional issue when VIPAs are being moved between TCP/IP stacks and dynamic routing is provided for those stacks by OMPROUTE. This movement of VIPAs can be done manually or automatically with Dynamic VIPAs. For the VIPAs to be correctly processed and advertised by the routing protocols, they (like all other interfaces) must be configured to OMPROUTE at the time that they become active on the TCP/IP stack. This configuration of VIPAs to OMPROUTE can be accomplished by:

     • Explicitly configuring each VIPA with its own OSPF_INTERFACE or INTERFACE statement
     • Configuring a range of DVIPAs with a single OSPF_INTERFACE or INTERFACE statement
     • Configuring a group of VIPAs with a single OSPF_INTERFACE or INTERFACE statement, by using the wildcard feature available on the interface statements

     The advised approach for configuring OMPROUTE for VIPAs that might move is to preconfigure the OMPROUTE on each TCP/IP stack with all VIPAs that can potentially exist on that stack at some time. Preconfiguring in this way prepares each OMPROUTE for the possible addition of the VIPAs to its stack. During times when the VIPAs do not exist on a particular OMPROUTE stack, the configuration information will not be used. However, during periods when the VIPAs do exist on that OMPROUTE stack, the configuration information is available for use by OMPROUTE. This method is advised because of its ability to respond to movement of the VIPAs between TCP/IP stacks without modification of the OMPROUTE configuration with each move.

     If the pre-configuration of VIPAs described in this topic is not done, it is still possible to define a VIPA to OMPROUTE such that it is properly processed and advertised when it becomes active on the corresponding TCP/IP stack. To do this configuration, add the appropriate OSPF_INTERFACE or INTERFACE statement to the OMPROUTE configuration file and then cause OMPROUTE to reread the configuration file by issuing the MODIFY procname,RECONFIG command.

     Rule: If you did not code GLOBAL_OPTIONS IGNORE_UNDEFINED_INTERFACES=YES in your OMPROUTE configuration file, you must modify the OMPROUTE configuration file and issue the RECONFIG command before the first time that the VIPA moves to the corresponding TCP/IP stack.
     Guideline: If you did code GLOBAL_OPTIONS IGNORE_UNDEFINED_INTERFACES=YES in your OMPROUTE configuration file, you can use OMPROUTE reconfiguration to add a definition for a VIPA interface that is or was active in the stack but ignored by OMPROUTE. However, OMPROUTE does not associate the VIPA with the new definition until the interface is deleted from the stack and readded, either by DVIPA movement or by some other method.

   Method of assigning interface definitions to stack interfaces (wildcard and explicit):

   Wildcard interface definitions can be a convenient way of making your interface definitions easier. However, to avoid unintended results, be sure to understand how they are parsed, and how different types of interface definitions interact with each other. The following outline shows the algorithm that OMPROUTE uses to find the matching definitions in the OMPROUTE configuration file for an IPv4 stack interface.

   1. Search for a RIP_Interface definition for the interface as follows:
      1. Search for an explicit matching RIP_Interface definition (IP address matches exactly if a dynamic VIPA, otherwise name and IP address match exactly). If found, use that definition and go to step b.
      2. If the interface is a dynamic VIPA, search for a RIP_Interface definition that matches as a dynamic VIPA wildcard. A matching dynamic VIPA wildcard definition is one where the definition IP address matches the value that is obtained by ANDing the definition subnet mask with the interface home address. The definition name parameter is ignored during a search for a dynamic VIPA wildcard definition. If a matching dynamic VIPA wildcard definition is found, use that definition and go to step b.
      3. Search for a one-octet wildcard RIP_Interface definition (n.n.n.*), where the first three octets match the first three octets of the interface home address and the name matches the interface link name. If found, use that definition and go to step b.
      4. Search for a two-octet wildcard RIP_Interface definition (n.n.*.*), where the first two octets match the first two octets of the interface home address and the name matches the interface link name. If found, use that definition and go to step b.
      5. Search for a three-octet wildcard RIP_Interface definition (n.*.*.*), where the first octet matches the first octet of the interface home address and the name matches the interface link name. If found, use that definition and go to step b.
      6. Search for a one-octet wildcard RIP_Interface definition (n.n.n.*), where the first three octets match the first three octets of the interface home address, ignoring the name parameter when coded. If found, use that definition and go to step b.
      7. Search for a two-octet wildcard RIP_Interface definition (n.n.*.*), where the first two octets match the first two octets of the interface home address, ignoring the name parameter when coded. If found, use that definition and go to step b.
      8. Search for a three-octet wildcard RIP_Interface definition (n.*.*.*), where the first octet matches the first octet of the interface home address, ignoring the name parameter when coded. If found, use that definition and go to step b.
      9. If there is a four-octet wildcard RIP_Interface definition (*.*.*.* or ALL), use that definition and go to step b.
         Restriction: Only 1 four-octet wildcard of each type (OSPF_INTERFACE or RIP_INTERFACE) is allowed.
   2. Search for an OSPF_Interface definition for the interface. This step is done regardless of the outcome of step a. The steps for searching OSPF_Interface definitions are the same as the steps for searching RIP_Interface definitions, except that OSPF_Interface definitions are searched.
   3. If either a RIP_Interface or an OSPF_Interface definition, or both, are found, the algorithm is complete. In this case, Interface definitions are not searched. If neither a RIP_Interface or an OSPF_Interface definition was found, go to step d.
   4. Search for an Interface definition for the interface. The steps for searching Interface definitions are the same as the steps for searching RIP_Interface statements, except that Interface definitions are searched.
   5. If no definitions are found, check the value of Global_Options Ignore_Undefined_Interfaces. If this option is turned on, the interface is ignored. If it is not turned on, the interface is treated as if it were defined with an Interface statement, with an MTU value of 576 and a subnet mask of the class mask.
   The algorithm is complete. Key conclusions of this algorithm are as follows:

   • A wildcard interface definition with a matching name is preferred over a wildcard interface definition of the same type without a matching name, regardless of which definition is a more specific wildcard.
   • If the interface is not a dynamic VIPA, the subnet mask that is coded on the definition statement has no influence on which definition, wildcard or otherwise, is selected for an interface. The subnet mask is a characteristic of the definition, not a selection criterion.
   • If a RIP_Interface or an OSPF_Interface definition, or both, are found, Interface definitions are not considered. This means that any matching RIP_Interface or OSPF_Interface definition supersedes all Interface definitions, even if the Interface definitions are explicit or are more specific wildcard matches. For example, a three-octet wildcard OSPF_Interface definition supersedes an explicit Interface definition.
   • An interface can be both a RIP_Interface and an OSPF_Interface. OMPROUTE supports running both protocols over the same interface. However, an interface cannot be both an interface that runs no routing protocol (that is, defined with the Interface statement) and one that runs RIP, OSPF, or both.
6. Define IPv6 interfaces, if the IPv6 OSPF or IPv6 RIP protocol is used. Each IPv6 interface in use by the stack can be defined to OMPROUTE by using an IPV6_OSPF_INTERFACE, IPV6_RIP_INTERFACE, or IPV6_INTERFACE statement. Defining IPv6 interfaces to OMPROUTE is much simpler than defining IPv4 interfaces because you do not specify IP addresses or MTU sizes to OMPROUTE. Instead, you define interfaces by their names and OMPROUTE learns IP addresses and MTU sizes from the TCP/IP stack. Also, because multicast support is a basic requirement of IPv6, there are no non-broadcast multiaccess considerations or other considerations that might require definitions of neighbors or destination addresses.

   Use the following guidelines when you are configuring IPv6 interfaces to OMPROUTE:

   • An interface over which the IPv6 OSPF protocol is communicated with other routers must be configured with the IPV6_OSPF_INTERFACE statement.
   • An interface over which the IPv6 RIP protocol is communicated with other routers must be configured with the IPV6_RIP_INTERFACE statement.
   • All other interfaces can be configured with the IPV6_INTERFACE statement when OMPROUTE default values are not acceptable or you want to define more prefixes on the interface.
   • The interface name must be coded on the IPV6_INTERFACE, IPV6_OSPF_INTERFACE, and IPV6_RIP_INTERFACE statements. The value of the NAME parameter must match the interface name that is coded on the INTERFACE statement in the TCP/IP profile. Wildcard names that end with an asterisk (*) can be coded. For example, OSAQDIO* would match stack interfaces named OSAQDIO1, OSAQDIO2, OSAQDIOABC, and so on.

     If the interface is dynamically generated by the TCP/IP stack, its name parameter must match what is generated by the TCP/IP stack. Interfaces that are dynamically generated by the TCP/IP stack are named as follows:

     • An IPv6 dynamic XCF interface that is generated to attach to other TCP/IP stacks within the same z/OS host is always named EZ6SAMEMVS.
     • An IPv6 dynamic XCF interface that is generated to attach to TCP/IP stacks in another z/OS image is always named EZ6XCFxx, where xx is the SYSCLONE value of the other z/OS host.

     If the routing parameters for your dynamic XCF interfaces are all to be the same, you can use wildcard definitions to avoid having to know and build definitions for every possible dynamic XCF interface on your system. For example, a wildcard definition for name EZ6* would match all dynamic XCF interfaces that can be generated on a TCP/IP stack. A wildcard definition for EZ6XCF* would match all dynamic XCF interfaces that can be generated to attach to other z/OS images.

     The following definition would define all IPv6 dynamic XCF interfaces to OMPROUTE, with the hello and dead router intervals changed from the default values:

     IPV6_OSPF_INTERFACE
     	NAME=EZ6*
     	HELLO_INTERVAL = 30
     	DEAD_ROUTER_INTERVAL = 120;

     If the default values of 10 and 40 for the hello and dead router intervals are acceptable, this definition can be simplified even more:

     IPV6_OSPF_INTERFACE
     	NAME=EZ6*;

   • To define one or more prefixes on an interface, use the PREFIX parameter on the IPV6_OSPF_INTERFACE, IPV6_RIP_INTERFACE, and IPV6_INTERFACE statements. You must use the PREFIX parameter only for prefixes that you must define to an interface, which cannot be learned using IPv6 router discovery. Also note that prefixes defined to OMPROUTE in this manner are not used by TCP/IP to autoconfigure home addresses on the interface.

     The following sample shows an IPv6 OSPF interface with prefixes defined:

     IPV6_OSPF_INTERFACE
     	NAME=OSAQDIO4L6
     	PREFIX=2001:0DB8:1::/48
     	PREFIX=2001:0DB8:2::/48;

     The prefixes defined in this manner on an IPv6 OSPF interface are advertised as reachable, and are also included in the link LSA generated by OMPROUTE, so all IPv6 OSPF routers on the link will know they are local prefixes. If OMPROUTE is also running IPv6 RIP, they are also advertised into the IPv6 RIP autonomous system as reachable, if IPv6 RIP filters permit it.

     The following sample shows an IPv6 RIP interface with prefixes defined:

     IPV6_RIP_INTERFACE
     	NAME=OSAQDIO3L6
     	PREFIX=2001:0DB8:3::/48
     	PREFIX=2001:0DB8:4::/48;

     The prefixes defined in this manner on an IPv6 RIP interface are advertised into the IPv6 RIP autonomous system as reachable if IPv6 RIP filters permit it. They are also advertised into the IPv6 OSPF autonomous system as reachable, if OMPROUTE is running IPv6 OSPF and is configured as an IPv6 AS boundary router importing RIP routes.

     The following sample shows an IPv6 generic interface with prefixes defined:

     IPV6_INTERFACE
     	NAME=OSAQDIO2L6
     	PREFIX=2001:0DB8:5::/48
     	PREFIX=2001:0DB8:6::/48;

     The prefixes defined in this manner on an IPv6 generic interface are advertised into the RIP autonomous system as reachable, if OMPROUTE is running IPv6 RIP and IPv6 RIP filters permit it. They are also advertised into the IPv6 OSPF autonomous system as reachable, if OMPROUTE is running IPv6 OSPF and is configured as an IPv6 AS boundary router importing direct routes.

   Method of assigning interface definitions to stack interfaces (wildcard and explicit):

   For IPv6 interfaces, interface-name wildcards can be used to simplify definitions. However, be sure to understand how they are parsed, and how different types of interface definitions interact with each other, to avoid unintended results. The following outline shows the algorithm OMPROUTE uses to find the matching definitions in the OMPROUTE configuration file for an IPv6 stack interface.

   1. Search for an IPv6_RIP_Interface definition for the interface as follows:
      1. Search for an explicit matching IPv6_RIP_Interface statement for the interface. This match is one where the name parameter exactly matches the interface name. If one is found, use that definition and go to step b.
      2. Search for the best IPv6_RIP_Interface wildcard match for the name. The IPv6_RIP_Interface wildcard definitions are searched, starting with the most specific (longest wildcard name string) and checking each in order of declining specificity until a match is found. As soon as a match is found, use that definition and go to step b.
   2. Search for an IPv6_OSPF_Interface definition for the interface. This step is done regardless of the outcome of step a. The steps for searching IPv6_OSPF_Interface definitions are the same as the steps for searching IPv6_RIP_Interface definitions, except that IPv6_OSPF_Interface definitions are searched.
   3. If either an IPv6_RIP_Interface or an IPv6_OSPF_Interface definition, or both, are found, the algorithm is complete. In this case, IPv6_Interface definitions are not searched. If neither an IPv6_RIP_Interface or an IPv6_OSPF_Interface definition was found, go to step d.
   4. Search for an IPv6_Interface definition for the interface. The steps for searching IPv6_Interface definitions are the same as the steps for searching IPv6_RIP_Interface statements, except that IPv6_Interface definitions are searched.
   5. If no definitions are found, check the value of Global_Options Ignore_Undefined_Interfaces. If this option is turned on, the interface is ignored. If it is not turned on, the interface is treated as if it were defined with an IPv6_Interface statement. Default values are used for all parameters.

   The algorithm is complete. Key conclusions of this algorithm are as follows:

   • If an IPv6_RIP_Interface definition, an IPv6_OSPF_Interface definition, or both, are found, IPv6_Interface definitions are not considered. This means that any matching IPv6_RIP_Interface or IPv6_OSPF_Interface definition supersedes all IPv6_Interface definitions, even if the IPv6_Interface definitions are explicit or more specific wildcard matches. For example, an IPv6_OSPF_Interface definition with a name parameter of V* supersedes any IPv6_Interface, explicit or wildcard, with a name parameter that begins with V. In this case, the IPv6_Interface definition is redundant and can never be used. If OMPROUTE detects this case, it issues message EZZ8068I and deletes the redundant IPv6_Interface definition.
     Note: If an IPv6_Interface definition was already selected for an interface that is installed in the stack, and then an IPv6_OSPF_Interface or IPv6_RIP_Interface definition that would make that IPv6_Interface definition redundant is added by using RECONFIG, OMPROUTE issues message EZZ8069I and retains the IPv6_Interface definition.
   • An interface can be both an IPv6_RIP_Interface and an IPv6_OSPF_Interface. OMPROUTE supports running both protocols over the same interface. However, an interface cannot be both an interface that runs no routing protocol (that is, defined with the IPv6_Interface statement) and one that runs IPv6 RIP, IPv6 OSPF, or both.
7. Define interface costs (OSPF_INTERFACE, RIP_INTERFACE, IPV6_OSPF_INTERFACE, and IPV6_RIP_INTERFACE). Both the OSPF and RIP protocols have a cost value that is associated with interfaces. With both protocols, the cost of a route to reach a destination is the sum of the costs of each link to be traversed on the way to the destination. In the sample network that is shown in Figure 1, the cost of a route to get from TCPCS7 to router 3.3.3.3 through TCPCS4 is the cost of the link from TCPCS7 to TCPCS4 plus the cost of the link from TCPCS4 to router 3.3.3.3.

   The method for configuring cost values differs between the OSPF and RIP protocols. Configure the cost values of OSPF links to ensure that preferred routes to destinations have a lower cost than less preferable routes. The less preferable routes, with the higher cost, are not used except upon failure of the preferred routes.

   For the following examples, the sample network that is shown in Figure 1 is used and the convention stack (interface) is used to refer to the cost configured for a particular interface on a stack. For instance, TCPCS7(9.67.106.7) refers to the cost configured for interface 9.67.106.7 on TCPCS7. While these examples use the IPv4 portion of the sample network, the same methods for computing route costs would also be used by the IPv6 portion.

   The following three routes are possible from TCPCS7 to router 3.3.3.3:

   • Direct (TCPCS7 to 3.3.3.3)
   • Through TCPCS4 (TCPCS7 to TCPCS4 to 3.3.3.3)
   • Through router 8.8.8.8 and TCPCS4 (TCPCS7 to 8.8.8.8 to TCPCS4 to 3.3.3.3)

   If the preferred route from TCPCS7 to router 3.3.3.3 is through TCPCS4, then interface costs must be configured such that the following conditions are true:

   TCPCS7(9.67.106.7) + TCPCS4(9.67.101.4) < TCPCS7(9.67.102.7) 	
   TCPCS7(9.67.106.7) + TCPCS4(9.67.101.4) < TCPCS7(9.67.100.7) + 
   8.8.8.8(9.67.105.8) + TCPCS4(9.67.101.4)

   The reasons for preferring one route over another are numerous. One approach for assigning OSPF link costs would be to set the costs to values inversely proportional to the bandwidth of the physical media. This would result in higher bandwidth routes with lower costs, thus becoming the preferred routes.

   The cost values of RIP links are generally set to a value of 1. This results in the cost of a route to a destination being the number of hops to reach the destination. In the sample network, this would result in the three possible RIP routes from TCPCS7 to router 3.3.3.3 having the following costs:

   • Direct (TCPCS7 to 3.3.3.3), cost = 1
   • Through TCPCS4 (TCPCS7 to TCPCS4 to 3.3.3.3), cost = 2
   • Through router 8.8.8.8 and TCPCS4 (TCPCS7 to 8.8.8.8 to TCPCS4 to 3.3.3.3), cost = 3

   If it was desirable that the route through TCPCS4 be the preferred route, this can be accomplished by increasing the cost of getting directly from TCPCS7 to router 3.3.3.3. This can be done by increasing either the out metric for 9.67.102.3 on router 3.3.3.3 or the in metric for 9.67.102.7 on TCPCS7. Take care when you are increasing in metric and out metric values to be sure that the cost to reach any destination does not exceed the RIP maximum of 15.

   • IPv4 OSPF and RIP

     The cost value of an OSPF interface is set with the COST0 parameter of the OSPF_INTERFACE statement. The in metric and out metric of a RIP interface are set with the IN_METRIC and OUT_METRIC parameters of the RIP_INTERFACE statement.

   • IPv6 OSPF and RIP

     The cost value of an IPv6 OSPF interface is set with the COST parameter of the IPV6_OSPF_INTERFACE statement. The in metric and out metric of an IPv6 RIP interface are set with the IN_METRIC and OUT_METRIC parameters of the IPV6_RIP_INTERFACE statement.

8. Configure virtual links, if the OSPF protocol is used. The OSPF protocol is dependent upon complete connectivity of the backbone area. To maintain backbone connectivity, each backbone router must be interconnected. If the configuration of an OSPF autonomous system is such that the backbone area becomes separated into two or more disconnected sections, connectivity must be restored for the protocol to work correctly. This can be done by using a virtual link. Do not confuse an OSPF virtual link with a VIPA link. Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area.
   • IPv4 OSPF

     The VIRTUAL_LINK statements specify the router ID of the link endpoint and must be configured at both endpoints. In the sample network that is shown in Figure 1, a virtual link is configured between TCPCS4 and TCPCS7 to restore backbone connectivity through area 1.1.1.1.

     TCPCS4:
     VIRTUAL_LINK
        Virtual_Endpoint_RouterID=7.7.7.7
        Links_Transit_Area=1.1.1.1;

     TCPCS7:
     VIRTUAL_LINK
        Virtual_Endpoint_RouterID=4.4.4.4
        Links_Transit_Area=1.1.1.1;

   • IPv6 OSPF

     The IPV6_VIRTUAL_LINK statements specify the router ID of the link endpoint and must be configured at both endpoints. In the sample network, a virtual link is configured between TCPCS64 and TCPCS67 to restore backbone connectivity through area 6.6.6.6.

     TCPCS64:
     IPV6_VIRTUAL_LINK
        Virtual_Endpoint_RouterID=67.67.67.67
        Links_Transit_Area=6.6.6.6;

     TCPCS67:
     IPV6_VIRTUAL_LINK
        Virtual_Endpoint_RouterID=64.64.64.64
        Links_Transit_Area=6.6.6.6;

9. Manage high-cost links, if the OSPF protocol is used. The periodic nature of OSPF routing traffic requires a link's underlying data-link connection to be constantly open. This can result in unwanted usage charges on network segments whose costs are high. There are two configuration steps that can be taken to inhibit the periodic nature of the protocol.

   The first step that can be taken is to define the link as a demand circuit. When this is done, link state advertisements (LSAs) sent over the interface are not periodically refreshed. Only LSAs with real changes are readvertised. In addition, aging of these LSAs is disabled such that they will not age out of the link state database.

   Another step that can be taken is to define hello suppression for the link. Hello suppression is meaningful only if the link is a demand circuit and is either point-to-point or point-to-multipoint. Hello suppression inhibits the periodic transmission of OSPF hello packets.

   • IPv4 OSPF

     To define OSPF interfaces as demand circuits, the Demand_Circuit=YES parameter must first be specified on the global OSPF configuration statement. Then, the OSPF_INTERFACE statement for each interface to be configured as a demand circuit must be specified with the Demand_Circuit=YES parameter. Use the Hello_Suppression parameter of the OSPF_INTERFACE statement to configure hello suppression. For more information about configuring the Hello_Suppression parameter on the OSPF_INTERFACE statement, see z/OS Communications Server: IP Configuration Reference. If hello suppression is implemented, the PP_Poll_Interval parameter of the OSPF_INTERFACE statement can be used to specify the interval at which OMPROUTE attempts to contact a neighbor to reestablish a neighbor relationship when the relationship failed, but the interface is still available.

   • IPv6 OSPF

     To define IPv6 OSPF interfaces as demand circuits, the Demand_Circuit=YES parameter must first be specified on the global IPV6_OSPF configuration statement. Then, the IPV6_OSPF_INTERFACE statement for each interface to be configured as a demand circuit must be specified with the Demand_Circuit=YES parameter. Use the Hello_Suppression parameter of the IPV6_OSPF_INTERFACE statement to configure hello suppression. For more information about configuring the Hello_Suppression parameter on the IPV6_OSPF_INTERFACE statement, see z/OS Communications Server: IP Configuration Reference. If hello suppression is implemented, the PP_Poll_Interval parameter of the IPV6_OSPF_INTERFACE statement can be used to specify the interval at which OMPROUTE attempts to contact a neighbor to reestablish a neighbor relationship when the relationship failed, but the interface is still available.

10. Define RIP filters, if the RIP protocol is used. RIP Filters can be configured to OMPROUTE such that certain RIP routing information is not broadcast out to other routers and/or accepted from other routers. The filters can be applied to individual RIP interfaces or to all RIP interfaces. When you are defining a filter, a filter type (sending or receiving) is specified along with values that identify the route information to be filtered. By using filters, an installation can limit the amount of RIP routing information broadcast into the network and/or the amount of RIP routing information that is maintained by OMPROUTE. In addition, filters can be used to hide destination addresses from portions of the network.
    • IPv4 RIP
      To configure a filter for an individual RIP interface, use the FILTER parameter of the RIP_INTERFACE statement. To configure a filter that applies to all IPv4 RIP interfaces, use the global FILTER statement. In the sample network that is shown in Figure 1, if you wanted to hide the 10.1.1.0 subnet from TCPCS6 (and all routers and hosts on the remote side of TCPCS6), you can define the following filter on TCPCS7:

      Filter=(nosend,10.1.1.0,255.255.255.0);

    • IPv6 RIP

      To configure a filter for an individual IPv6 RIP interface, use the FILTER parameter of the IPV6_RIP_INTERFACE statement. To configure a filter that applies to all IPv6 RIP interfaces, use the global IPV6_RIP_FILTER statement. In the sample network that is shown in Figure 1, for example, if you wanted to hide the 2001:0DB8:0:A1B/64 prefix from TCPCS4, you can define the following filter on TCPCS4:

      IPv6_RIP_Filter=(noreceive,2001:0DB8:0:A1B/64);

11. Define route precedence in a multiprotocol environment, if the OSPF protocol is used. This discussion of route precedence is complicated. If only the OSPF or IPv6 OSPF routing protocol, or both, are used in your network, route precedence is less of a concern. If, in addition, none of your OSPF or IPv6 OSPF routers are configured as AS boundary routers, the route precedence concern is entirely eliminated. For environments with multiple protocols or AS boundary routers, the following information is provided. In this discussion, RIP is meant to apply to both RIP and IPv6 RIP, OSPF is meant to apply to both OSPF and IPv6 OSPF, and the OSPF configuration statement is meant to apply to both the OSPF statement and the IPV6_OSPF statement.

    OMPROUTE applies an order of precedence in choosing between two routes to the same destination that were learned through different routing protocols or by using information that is provided by an OSPF AS boundary router. To describe this order of precedence that is applied by OMPROUTE, a few terms must first be defined.

    RIP route

    A route learned through the RIP protocol. A RIP route is generated by using information that is provided in a RIP packet from a neighboring router. For example, in the sample network that is shown in Figure 1, the route from TCPCS7 to destination subnet 30.1.1.0 is a RIP route.

    OSPF internal route

    A route learned through the OSPF protocol where the entire path traversed to reach the destination lies within the OSPF autonomous system. For example, in the sample network that is shown in Figure 1, the route from TCPCS7 to destination 9.67.108.2 on Router 2.2.2.2 is an OSPF internal route.

    OSPF external route

    A route learned through the OSPF protocol where part of the path traversed to reach the destination does not lie within the OSPF autonomous system. The path leaves the autonomous system when it uses information brought into the OSPF autonomous system by an AS boundary router. This information that is brought into the OSPF AS can be information that is imported from a different autonomous system (for example, RIP) or information about destinations that are statically configured on or directly connected to the AS boundary router. For example, in the sample network that is shown in Figure 1, the route from TCPCS4 to destination 9.67.103.6 on TCPCS6 is an OSPF external route. TCPCS7, configured as an AS boundary router, imported information about that destination into the OSPF AS from the RIP AS.

    OSPF external routes fall into two categories that are based upon the setting of the multiprotocol comparison value. If the comparison value is set to Type1 on the AS boundary router that imports the external information into the OSPF AS, then OSPF external routes that are generated by using this information are OSPF type 1 external routes. If the comparison value is set to Type2 on the AS boundary router, then the generated routes are OSPF type 2 external routes. For example, in the sample network that is shown in Figure 1, if the comparison value on TCPCS7 (an AS boundary router) is set to Type1, the route from TCPCS4 to destination 9.67.103.6 on TCPCS6 is an OSPF type 1 external route. If the comparison value on TCPCS7 is set to Type2, the route is an OSPF type 2 external route.

    Multiprotocol comparison

    You can configure this comparison value to allow for the specification of how route costs from different autonomous systems are treated when they coexist. In OMPROUTE, you can configure this value by using the COMPARISON parameter on the OSPF or IPV6_OSPF configuration statements. When COMPARISON=Type1 is configured, the route cost values used within different autonomous systems (for example, the OSPF AS and the RIP AS) are considered comparable. With COMPARISON=Type2 configured, the route cost values used with the different autonomous systems are considered non-comparable.

    The comparison value can be used in several different ways, depending on the function that is being provided by a router:

    • As an AS boundary router, OMPROUTE uses the comparison value to determine the type of external routes (type 1 or type 2) that are generated by routers in the OSPF AS by using routing information that the AS boundary router imports into the OSPF AS.
    • As an AS boundary router, OMPROUTE also uses the comparison value in determining how route cost values are assigned when routes are imported from the OSPF AS into the RIP AS.
      • When COMPARISON=Type1 is configured (indicating that cost values are comparable), an OSPF route that is imported into the RIP AS is advertised with the actual cost of the OSPF route. For example, in the sample network, if TCPCS7 is configured with COMPARISON=Type1 and the OSPF route from TCPCS7 to destination 9.67.108.2 on TCPCS2 has a cost of 7, then TCPCS7 advertises into the RIP AS a RIP route to that destination with a cost of 7.
        Notes:

        1. An exception to this rule (defining how OSPF routes are advertised into the RIP AS when COMPARISON=Type1) occurs when the OSPF route to be imported is an OSPF type 2 external route. In this case, the route is not advertised into the RIP AS at all.
        2. It is important to remember the requirement that all destinations in the RIP AS must be reachable with a cost no greater than 15. Using COMPARISON=Type1 requires that the cost values of OSPF routes be low. Any destinations in the OSPF AS that can be reached only from the RIP AS with a cost greater than 15 become unreachable.
      • When COMPARISON=Type2 is configured (indicating that cost values are non-comparable), an OSPF route that is imported into the RIP AS is advertised with a cost of 1. If a router in the RIP AS has two possible routes to a destination, one internal to the RIP AS and another that was imported from OSPF, this approach results in the route that is imported from OSPF being favored. For example, in the sample network that is shown in Figure 1, if TCPCS7 is configured with COMPARISON=Type2 and TCPCS7 can somehow reach a destination in the 30.1.1.0 subnet without passing through TCPCS6 (by using links that are not shown in the sample), then TCPCS7 advertises into the RIP AS a RIP route to the destination with a cost of 1. As a result, TCPCS6 determines that the destination can be reached through TCPCS7 with a cost of 2. If the cost of the route for TCPCS6 to reach the destination internal to the RIP AS is greater than 2, then the route through TCPCS7 is chosen.
        Note: An exception to this rule (defining how OSPF routes are advertised into the RIP AS when COMPARISON=Type2) occurs when the OSPF route to be imported is an OSPF type 2 external route. In this case, the route is advertised into the RIP AS with the actual cost of the OSPF type 2 external route.
    • As any router that has routing information from different autonomous systems, OMPROUTE uses the comparison value while it is choosing between the routes generated by using the information from the different autonomous systems. How the comparison value is used in this case is shown in Table 1.

    Given these definitions, the order of precedence that is used in choosing between multiple routes to the same destination, which were learned through the different protocols or by using information that is provided by an OSPF AS boundary router, can be shown in Table 1. In Table 1, Source comparison refers to the setting of the comparison value (by using the COMPARISON parameter on the OSPF configuration statement) on the router that is using the order of precedence to choose between the multiple routes. Route 1 and Route 2 are the two possible routes that are being chosen between.

    Table 1. Route precedence

    Source comparison	Route 1 type	Route 2 type	Route chosen
    Type 1	OSPF internal	RIP	OSPF internal
    Type 1	OSPF internal	OSPF type 1 external	OSPF internal
    Type 1	OSPF internal	OSPF type 2 external	OSPF internal
    Type 1	RIP	OSPF type 1 external	Lowest cost route
    Type 1	RIP	OSPF type 2 external	RIP route
    Type 1	OSPF type 1 external	OSPF type 2 external	OSPF type 1 external
    Type 2	OSPF internal	RIP	OSPF internal
    Type 2	OSPF internal	OSPF type 1 external	OSPF internal
    Type 2	OSPF internal	OSPF type 2 external	OSPF internal
    Type 2	RIP	OSPF type 1 external	OSPF type 1 external
    Type 2	RIP	OSPF type 2 external	Lowest cost route
    Type 2	OSPF type 1 external	OSPF type 2 external	OSPF type 1 external