Configuring the OSPF Protocol

Planning Your OSPF Configuration

The following is a suggested sequence of steps in planning for OSPF routing in your autonomous system:

Enabling OSPF

The default router identifier used by OSPF is the address of the first interface on the router encountered by gated. To set the router identifier to a specific address, specify the routerid interface statement in the Definition class of the /etc/gated.conf file.

	NOTE: The OSPF protocol should be enabled only for routers. Once the OSPF protocol is enabled for a system, the system is treated as a router by other routers, and not a host.

The OSPF protocol is enabled for a node with the ospf statement in the Protocol class of the /etc/gated.conf file. The clause yes (or on) tells gated to enable the OSPF protocol at this node and process all OSPF packets coming in from other nodes. If you do not specify an OSPF line in your configuration file, ospf no is assumed. The clause no (or off) tells gated to disable the OSPF protocol at this node.

The following is an example of the statement to enable OSPF:

ospf yes { ... }

Other statements that are defined for the OSPF protocol configuration are explained in the following sections.

Defining Areas

Every OSPF router is associated with one or more areas. The area statement identifies an OSPF area. The value is in the form of a dotted quad, or a number between 1 and 4294967295. To define an area, you also need to specify the following:

Note that the configuration of an area border router contains multiple area definitions; a different router interface is defined for each area. Figure 8-4 “Area Border Router Configuration Example” shows an example of an area border router that is connected to area 0.0.0.1 through interface 193.2.1.33 and to area 0.0.0.2 through interface 193.2.1.17.

Figure 8-4 Area Border Router Configuration Example

The following is an example of the area definitions in the router's /etc/gated.conf file:

ospf yes {
      area 0.0.0.1 {
        interface 193.2.1.33 {
               ...
        } ;
       } ;
       area 0.0.0.2 {
         interface 193.2.1.17 {
               ...
         } ;
       } ;
   } ;

There are various other characteristics that you can define for the area and for the interface(s). The following sections describe the configuration statements that you use in defining an area.

Networks

The networks statement defines the address ranges that make up an OSPF area. This definition applies only to area border routers, where multiple areas are specified, and is required only if you need to compress a number of subnets using a network mask.

Inside the networks statement, each IP address range is specified by a network address followed by a hexadecimal bit mask. For example, the following address range begins with the network address 193.2.1.16 and includes the first 15 addresses in that network (193.2.1.17 through 193.2.1.31):

193.2.1.16 mask 0xfffffff0

Many separate networks can be specified in an address range. Area border routers advertise a single route for each address range.

Figure 8-5 “Network Configuration Example” shows an example of a router that is connected to area 0.0.0.1 through interface 193.2.1.33. The attached network consists of addresses 193.2.1.33 through 193.2.1.47. The other network in the area consists of addresses 193.2.1.17 through 193.2.1.31.

Figure 8-5 Network Configuration Example

The following is an example of the network definition in Router A's /etc/gated.conf file:

ospf yes area 0.0.0.1 networks { 193.2.1.16 mask 0xfffffff0 ; 193.2.1.32 mask 0xfffffff0 ; } ; interface 193.2.1.33 { ... } ; } ; ...

Interfaces

The interface statement in the OSPF Protocol definition specifies which interface to use when communicating with the specified network(s). The interface may be specified with an address (for example, 193.2.1.36), a domain or interface name (for example, lan0 or lan1), a wildcard name (for example, lan*), or all. (The order of precedence is address, name, wildcard name, all.) Multiple interface statements may be specified with different clauses. If a clause is specified more than once, the instance with the most specific interface reference is used.

The cost clause can optionally be specified to define a cost of sending a packet on the interface. This cost is advertised as the link cost for this interface. See “Cost” for more information about setting interface costs.

You can also enable or disable the interface definition. If disable is not explicitly specified, an interface definition is assumed to be enabled.

OSPF supports three types of network interfaces:

• A multicast (or "broadcast") network is a network that supports two or more attached routers and allows a single message to be addressed to a set of network nodes at the same time. An example of a multicast network is an Ethernet LAN.

• A non-broadcast multi-access (NBMA) network is a network that supports multiple attached routers, but does not support broadcasting of messages. An example of an NBMA network is an X.25 PDN.

• A point-to-point network is a network that joins a single pair of routers. An example of a point-to-point network is a 56Kb serial line.

The definition for each type of interface is described separately in the following sections.

Multicast Interfaces

On multicast networks, an OSPF router dynamically detects its neighbor routers through the OSPF Hello message. The following statements are defined for a multicast type interface:

retransmitinterval is the number of seconds between retransmission of link states, database description, and link state request packets. This value should exceed the expected round-trip delay between any two routers in the network. A sample value for a LAN is 5 seconds.

• Default: None (you must specify a value)

• Range: Integer between 0 - 65535

transitdelay is the number of seconds it takes to transmit a Link State Update Packet over this interface. This value must take into account the transmission and propagation delays for the interface. It must be greater than 0. A sample value for a LAN is 1 second.

• Default: None (you must specify a value)

• Range: Integer between 1 - 65535

priority should be configured only for interfaces to multi-access networks. This value specifies the priority of the router to become the Designated Router. When two routers attached to a network both attempt to become the Designated Router, the one with the highest router priority value takes precedence.

• Default: None (you must specify a value for multi-access networks)

• Range: 8-bit unsigned integer between 0 - 255. 0 means that the router is ineligible to become a designated router on the attached network.

hellointerval specifies the number of seconds between transmission of OSPF Hello packets. Smaller intervals ensure that changes in network topology are detected faster; however, routing traffic can increase. A sample value for an X.25 network is 30 seconds. A sample value for a LAN is 10 seconds.

• Default: None (you must specify a value)

• Range: Integer between 0 - 255

	NOTE: The hellointerval value must be the same for all OSPF routers.

routerdeadinterval specifies the number of seconds that hello packets are not received from a router before it is considered "down" or "inactive" by its neighbors. This value should be some multiple of the hellointerval value.

• Default: None (you must specify a value)

• Range: 0 - 65535

	NOTE: The routerdeadinterval value must be the same for all OSPF routers.

authkey is the password used to validate protocol packets received on the router interface. The value is one of the following: 1 to 8 decimal digits separated by periods, a 1-byte to 8-byte hexadecimal string preceded by 0x, or a string of 1 to 8 characters in double quotes.

• Default: None

• Range: Up to 8 bytes

	NOTE: To set an authkey value, the authtype clause must be set to 1 or simple for the area. See “Authentication” for more information about using OSPF authentication.

Figure 8-6 “Multicast Router Interface Example” shows an example of a router that is connected to a multicast network through interface 193.2.1.35.

Figure 8-6 Multicast Router Interface Example

The following is an example of the multicast interface definition in the router's /etc/gated.conf file:

interface 193.2.1.35 cost 5 { enable ; priority 15 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ;

Non-Broadcast Multi-Access (NBMA) Interface

On NBMA networks, certain configuration information, including the routers that are attached to the network, must be supplied in order for OSPF's Hello protocol to communicate with neighbor routers. An NBMA interface definition applies to both X.25 network interfaces as well as for systems that do not support IP multicast. An NBMA type interface is defined with the same statements as for a multicast type interface, with the following additions:

• The clause nonbroadcast must be specified in the interface statement.

• pollinterval specifies a rate at which hellos are sent when a neighboring router becomes inactive. (A router is considered inactive when hellos have not been received from the router for the amount of time specified by the routerdeadinterval definition.) The value of pollinterval should be larger than the value of hellointerval. A sample value for an X.25 network is 2 minutes.

  • Default: None (you must specify a value)

  • Range: 0 - 255

• routers specifies the list of routers that are attached to the non-broadcast network. Routers are defined by their IP interface addresses. Routers that are eligible to become Designated Routers must be defined as eligible.

Figure 8-7 “Non-Broadcast Router Interface Example” shows an example of a router (A) that is connected to an NBMA network through interface 193.2.1.35. Two other routers are also attached to the network: router B is connected through interface 193.2.1.33 and C is connected through interface 193.2.1.46. B and C are eligible to be Designated Routers.

Figure 8-7 Non-Broadcast Router Interface Example

The following is an example of the non-broadcast interface definition in router A's /etc/gated.conf file:

interface 193.2.1.35 nonbroadcast cost 5 { routers { 193.2.1.33 eligible ; 193.2.1.46 eligible ; } ; priority 15 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; pollinterval 20 ; } ;

Point-to-Point Interfaces

On point-to-point networks, an OSPF router dynamically detects its neighbor router by sending OSPF Hello packets. The following statements are defined for a point-to-point interface:

retransmitinterval is the number of seconds between retransmission of link states, database description, and link state request packets. This value should exceed the expected round-trip delay between any two routers in the network. A sample value for a LAN is 5 seconds.

• Default: None (you must specify a value)

• Range: 0 - 65535

hellointerval specifies the number of seconds between transmission of OSPF Hello packets. Smaller intervals ensure that changes in network topology are detected faster; however, routing traffic can increase. A sample value for an X.25 network is 30 seconds. A sample value for a LAN is 10 seconds.

• Default: None (you must specify a value)

• Range: 0 - 255

	NOTE: The hellointerval value must be the same for all OSPF routers.

routerdeadinterval specifies the number of seconds that hello packets are not received from a router before it is considered "down" or "inactive" by its neighbors. This value should be some multiple of the hellointerval value.

• Default: None (you must specify a value)

• Range: 0 - 65535

	NOTE: The routerdeadinterval value must be the same for all OSPF routers.

A point-to-point interface can be defined with or without a nonbroadcast clause. If the nonbroadcast clause is specified, then the pollinterval statement must be defined:

pollinterval specifies a rate at which hellos are sent when a neighboring router becomes inactive. (A router is considered inactive when hellos have not been received from the router for the amount of time specified by the routerdeadinterval definition.) The value of pollinterval should be larger than the value of hellointerval. A sample value for an X.25 network is 2 minutes.

• Default: None (you must specify a value)

• Range: 0 - 255

If the device at the other end of the point-to-point network is not an OSPF router, you can prevent Hello packets from being sent to it. (*** This is done using the stubhosts statement. stubhosts specifies the IP address or domain name of the non-OSPF host. The cost of sending a packet to the host must also be specified. (In most cases, the host has only a single connection to the network so the cost configured has no effect on routing.)

Figure 8-8 “Point-to-Point Router Interface Example” shows an example of a router (A) that is connected to a non-broadcast, point-to-point network through interface 193.2.1.1.

Figure 8-8 Point-to-Point Router Interface Example

The following is an example of the interface definition in router A's /etc/gated.conf file:

interface 193.2.1.1 nonbroadcast cost 5 { hellointerval 30 ; routerdeadinterval 30 ; retransmitinterval 30 ; pollinterval 30 ; } ;

Note that if the router (A) were connected to a multicast, point-to-point network, the nonbroadcast clause and the pollinterval statement must be omitted.

Stub Areas

By default, AS external link advertisements (routes to destinations outside the AS) are propagated to every router in every area in the AS. Certain OSPF areas can be configured as stub areas. AS external link advertisements are not flooded through stub areas. This reduces the size of the topology database that must be maintained by internal routers in the stub area and reduces the protocol traffic through the area. For example, if all inter-area traffic for an area must go through a single router, then it is not necessary for all routers in the area to receive inter-area routing information.

An area border router advertises in the stub area a default route as the summary of all the IP destinations that are reachable outside the AS. Summary link advertisements (routes to destinations outside the area but within the AS) continue to be sent into the stub area.

The stub statement specifies that the area is a stub area. A cost clause can optionally be defined that specifies the cost associated with the default route to be advertised in the stub area.

Figure 8-9 “Area Border Router Configuration Example” shows an example of an area border router that is connected to area 0.0.0.2 through interface 193.2.1.20. Since all traffic in and out of area 0.0.0.2 must pass through router A, it is not necessary for the area's internal routers, such as router B, to receive inter-area routing information.

Figure 8-9 Area Border Router Configuration Example

The following is an example of the stub area definition in the router's /etc/gated.conf file:

OSPF yes { area 0.0.0.2 { stub cost 5 ; networks { 193.2.1.16 mask 0xfffffff0 ; } ; interface 193.2.1.20 nonbroadcast cost 5 { enable ; routers { 193.2.1.17 eligible ; } ; priority 5 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; pollinterval 20 ; } ; } ; } ;

Defining Backbones

The OSPF backbone distributes routing information between areas. Backbones are defined with the same statements and clauses as areas. The stub statement may not be defined for a backbone. The backbone statement is used to define a router as a backbone router. If an OSPF internal or area boarder router is also a backbone router, the backbone statement must follow the area statement(s) in the /etc/gated.conf file. Whenever an area border router (a router connected to multiple areas) is configured, backbone information must be provided.

Figure 8-10 “Backbone Configuration Example” shows an example of two area border routers that form part of a backbone. Router A has interfaces to both area 0.0.0.1 and area 0.0.0.2, while router B has interfaces to areas 0.0.0.3 and 0.0.0.4. Router A is connected to router B through interface 15.13.115.156.

Figure 8-10 Backbone Configuration Example

The following is an example of the backbone router definition for router A's /etc/gated.conf file:

backbone {
      interface 15.13.115.156 {
        enable ;
        transitdelay 20 ;
        priority 20 ;
        hellointerval 30 ;
        routerdeadinterval 120 ;
        retransmitinterval 60 ;
        } ;
      } ;

If the router is directly attached via a point-to-point interface to a host that is not running OSPF, you can prevent OSPF Hello packets from being sent to the host. This is done by specifying the subhost statement with the host's address. A cost can optionally be defined.

	NOTE: Backbones must be directly-connected or "contiguous". In some gated implementations, a "virtual link" can be configured to join non-contiguous backbone routers. Virtual links are not supported on HP-UX systems.

Authentication

The OSPF protocol allows packets containing routing information to be authenticated. The authentication method used is configured on a per-area basis; different authentication methods may be used in different areas.

gated supports a simple password authentication method. You can also choose to have no authentication. The authtype statement is used to define the authentication method used for the area. 0 or none specifies that routing exchanges in the area are not authenticated. 1 or simple specifies that network passwords of up to 64 bits (8 characters) are used to authenticate packets received from routers in the area.

In the simple password authentication method, all routers that interface to a given network use the same password. The password is defined by the authkey statement in the router's interface definition. If a router is not configured with the same password as other routers in the network, the router's packets are discarded by other network routers. Note that the password is configured on a per-interface basis. If a router has interfaces to more than one network, different passwords may be configured. This is illustrated in Figure 8-11 “Simple Password Authentication”.

Figure 8-11 Simple Password Authentication

The following example shows an authtype statement that enables a simple password authentication for the routers in the area and an authkey statement in the interface definition that defines a password ("travis") to validate protocol packets received by the router:

area 0.0.0.1 {
    authtype simple ;
    networks {
      193.2.1.16 mask 0xfffffff0 ;
      193.2.1.32 mask 0xfffffff0 ;
      } ;
    interface 193.2.1.35 nonbroadcast cost 5 {
      routers {
        193.2.1.33 eligible ;
        193.2.1.46 eligible ;
      } ;
      priority 15 ;
      enable ;
      hellointerval 5 ;
      routerdeadinterval 20 ;
      retransmitinterval 10 ;
      pollinterval 20 ;
      authkey  " travis "  ;
    } ;
} ;

Cost

The outbound side of each router interface is associated with a configurable cost. Lower cost interfaces are more likely to be used in forwarding data traffic. Cost values are assigned at the discretion of the network or system administrator. While the value is arbitrary, it should be a function of throughput or capacity of the interface: the higher the value, the lower the throughput or capacity. Thus, the interfaces with the highest throughput or capacity should be assigned lower cost values than other interfaces. Interfaces from networks to routers have a cost of 0.

Figure 8-12 “Cost Configuration Example” shows an example network where costs have been specified for each interface.

Figure 8-12 Cost Configuration Example

In Figure 8-12 “Cost Configuration Example”, there are two possible packet routes between nodes A and D: one route goes through node B and the other route goes through node C. The cost of each route is calculated as follows:

Node A to node B and node B to node D: 5+5 = 10

Node A to node C and node C to node D: 5+10 = 15

The lowest cost OSPF path between nodes A and D is therefore through node B. However, if there were a link failure between node B and LAN 2, packets would be rerouted through node C.

There are other places in the /etc/gated.conf file where cost can optionally be defined:

AS External Routes (AS Boundary Routers Only)

AS external (ASE) routes are paths to destinations that are outside the AS. Most ASE routes are routes to specific destinations. ASE routes are learned by AS boundary routers through another routing protocol, such as EGP, or through configured routes. gated supports the use of route information from other autonomous systems that use other routing protocols, such as EGP. AS external link advertisements are sent by AS boundary routers and are flooded throughout the AS (with the exception of configured stub areas). A single AS external link advertisement is sent for each external route that the AS boundary router has learned about.

Externally-defined routing information is kept separately from the OSPF routing information. In addition, the externally-defined routing information can be tagged, where the source of the information is identified and stored along with the route information.

Statements in the Control class of the /etc/gated.conf file control the importing of routes from routing protocols to a gated forwarding table and the exporting of routes from the gated forwarding table. See “Importing and Exporting Routes”.

The defaults statements in the OSPF protocol configuration are specified for AS boundary routers only. These statements specify how external routing information is handled by the OSPF protocol. The following can be defined in the defaults statements:

Sample OSPF Configuration

Figure 8-13 “OSPF Sample Configuration” shows an example of two areas. Area 1 is a non-stub area, while area 2 is configured as a stub area. Node B is an area border router between the two areas.

Figure 8-13 OSPF Sample Configuration

A: Internal Router (Non-Stub Area)

Set up /etc/gated.conf as follows:

# Router A Configuration (non-stub area) OSPF yes { area 0.0.0.1 { interface 193.2.1.35 cost 5 { priority 5 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ; } ;

Note that the configuration shown above is for a multicast interface. For an NBMA interface, the configuration in /etc/gated.conf would be set up as follows:

# Router A Configuration (non-stub area) OSPF yes { area 0.0.0.1 { interface 193.2.1.35 nonbroadcast cost 5 { routers { 193.2.1.33 eligible ; } ; priority 5 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; pollinterval 20 ; } ; } ; } ;

	NOTE: If you use IP multicasting in an area, every router and all intermediate network devices in that area must support IP multicasting.

B: Area Border Router

Set up /etc/gated.conf as follows:

OSPF yes { defaults { cost 5 ; } ; area 0.0.0.1 { interface 193.2.1.33 cost 5 { priority 15 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ;

area 0.0.0.2 { interface 193.2.1.17 cost 5 { priority 15 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ;

backbone { interface 15.13.115.156 cost 5 { enable ; priority 10 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ; } ;

C: Internal Router (Stub Area)

Set up /etc/gated.conf as follows:

OSPF yes { area 0.0.0.2 { stub cost 5 ; interface 193.2.1.20 cost 5 { priority 5 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ; } ;

The routing table on node A contains routes to 193.2.1.32 and 193.2.1.16. The routing table on node C in the stub area contains routes to LAN1 only and a default router.

Accessing the OSPF MIB

HP's gated also provides ospfagt, an OSPF Simple Management Network Protocol (SNMP) subagent that supports the OSPF MIB (Management Information Base) (see RFC 1253). The ospfagt subagent works with the HP SNMP Agent, snmpdm. If you are using an SNMP manager utility to manage your network, such as HP's OpenView Network Node Manager, you may also want to use HP's OSPF SNMP subagent.

To start ospfagt automatically at system bootup, set the environment variable OSPFMIB to 1 in the file /etc/rc.config.d/netdaemons.

To manually start ospfagt , enter:

/usr/sbin/ospfagt 

Note that gated must be running before ospfagt can be started. Both gated and ospfagt must be running in order to retrieve OSPF MIB objects.

To load the OSPF MIB, select "Load/Unload SNMP:MIBS ..." from the Options Menu of OpenView.