Notes on defining IPv4 interfaces

Each interface in use by the stack should be defined to MPRoute using an OSPF_INTERFACE, RIP_INTERFACE, or INTERFACE statement. This substep describes the differences between interface types that you should consider when configuring interfaces to MPRoute. 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 all other interfaces should be configured with the INTERFACE statement, or MPRoute should be configured to ignore undefined interfaces using the IGNORE_UNDEFINED_INTERFACES parameter of the GLOBAL_OPTIONS statement in the MPRoute configuration file. It is important that one or the other be done.

    If MPRoute is not configured to ignore undefined interfaces, it configures stack interfaces that are not defined to MPRoute 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, MPRoute overrides stack values with its default values unless the stack's value for the MTU has been specified on the LINK statement for an interface. To prevent these situations, either configure every interface, even those that are not using RIP or OSPF, or configure MPRoute to ignore undefined interfaces.

A VIPA interface is an exception to these guidelines and is discussed in more detail later in this substep.

TCP/IP enforces RFC rules against using either a subnetwork's 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's 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 two 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 three bits; for example, 255.255.255.248. In this case, there could be up to 6 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. MPRoute 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 imposed by network design.
  2. RIP version 1 uses broadcast and RIP version 2 uses multicast. RIP version 1 will not run on a medium that supports multicast but not broadcast, so the OSA-Express® microcode level must support broadcast. Some levels of OSA-Express microcode support multicasting but not broadcasting. In this case, RIP version 2, which relies on multicast, is recommended over RIP version 1, which relies on broadcast.

Configuring multi-access parallel interfaces: Whenever configuring multi-access parallel interfaces (primary and backup redundant interfaces having IP addresses in the same network) for MPRoute (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 additional information on the OSPF_INTERFACE statement, see OSPF_INTERFACE.

Point-to-point (For example CTC): For point-to-point interfaces, the destination IP address must be known to MPRoute. 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 MPRoute. Additionally, defining a destination address on an interface that is running OSPF or RIP allows MPRoute to learn and advertise a route to that destination address before a neighboring router has become 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 running OSPF, MPRoute does not advertise a host route to its own home address on the point-to-point interface. By default, MPRoute advertises a host route to the link destination, and relies on the router at the other end to advertise a host route to MPRoute's home address. This behavior is described by the OSPF architecture, RFC 1583 (OSPF version 2), section 12.4.1. This means that MPRoute's home address on the point-to-point link will not be advertised as reachable unless there is a neighboring router available to advertise it. MPRoute implements an extension 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 causes MPRoute to implement option 2 described in RFC 2328, section 12.4.1.1, and advertise a route to the point-to-point link's subnet address. This makes both endpoints reachable regardless of the status of a neighboring router.

If the interface is simply 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;

Non-broadcast network interfaces: If the OSPF or RIP protocol communicates with one or more routers over a non-broadcast network interface, MPRoute must know the IP addresses of the other routers (neighbors) with which it needs to 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 MPRoute with the parameters configured as follows:

  • DR_NEIGHBOR and/or the NO_DR_NEIGHBOR parameters 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. Note that 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: 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 MPRoute to know the IP addresses of the other routers on the network for OSPF or RIP packets to be communicated with those routers. MPRoute 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 assist in electing a designated router for the network.

Sample OSPF_INTERFACE: 
OSPF_INTERFACE	
	IP_Address=9.59.101.5
	Name=LINK1	
   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=LINK2
	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;

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. This would cause MPRoute 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 using DR_NEIGHBOR and/or NO_DR_NEIGHBOR parameters for OSPF_INTERFACEs and using NEIGHBOR parameters for RIP_INTERFACEs that are broadcast capable, but it is not required or recommended. If you define neighbors on these interfaces, you must define all of them, as MPRoute will not communicate RIP or OSPF to undefined neighbors if any are defined on an interface.

VIPA interfaces: If only the RIP protocol is used by MPRoute, VIPA interfaces should be defined with the INTERFACE statement. If only OSPF or if both OSPF and RIP are used by MPRoute, VIPA interfaces should be defined 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 MPRoute 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
Following are the conditions 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 MPRoute 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. VIPA host routes should not be suppressed for VIPAs whose subnet might exist on multiple hosts. It is up to the user to ensure these restrictions are enforced, as they are not and cannot be enforced by MPRoute.
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 in conjunction with the Send_Net_Routes, Send_Subnet_Routes, and Send_Host_Routes filters, or the FILTER statement with VIPA routes, indicates whether or not 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.

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. Following is the outline of the algorithm MPRoute uses to find the matching definitions in the MPRoute 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. If found, use that definition and go to step 2.
    2. 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's home address and the name matches the interface's link name. If found, use that definition and go to step 2.
    3. Search for a two-octet wildcard RIP_Interface definition (n.n.*.*), where the first two octets match the first two octets of the interface's home address and the name matches the interface's link name. If found, use that definition and go to step 2.
    4. Search for a three-octet wildcard RIP_Interface definition (n.*.*.*), where the first octet matches the first octet of the interface's home address and the name matches the interface's link name. If found, use that definition and go to step 2.
    5. 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's home address, ignoring the name parameter if coded. If found, use that definition and go to step 2.
    6. Search for a two-octet wildcard RIP_Interface definition (n.n.*.*), where the first two octets match the first two octets of the interface's home address, ignoring the name parameter if coded. If found, use that definition and go to step 2.
    7. Search for a three-octet wildcard RIP_Interface definition (n.*.*.*), where the first octet matches the first octet of the interface's home address, ignoring the name parameter if coded. If found, use that definition and go to step 2.
    8. If there is a four-octet wildcard RIP_Interface definition (*.*.*.* or ALL), use that definition and go to step 2.

      Restriction: Only one four-octet wildcard of each type (OSPF_INTERFACE or RIP_INTERFACE) is allowed.

  2. Search for an OSPF_Interface definition for the interface. Note that this step is done regardless of the outcome of step 1. The steps for searching OSPF_Interface definitions are the same as the steps for searching RIP_Interface definitions described above, 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 nor an OSPF_Interface definition was found, go to step 4.
  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 described above, 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 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. MPRoute 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.