OSPF Network Types

OSPF operates differently over broadcast, point-to-point, point-to-multipoint, and NBMA networks. For example, Designated Routers (DRs) are only elected on the broadcast and NBMA network types, and the default hello interval for Juniper Networks routers is 10 seconds for all network types except NBMA, which use a 30-second hello interval. It should be obvious to the reader of this book that incorrect or mismatched network type settings can result in adjacency formation problems.

By default, LAN interfaces operate as a broadcast (LAN) network type, while all other interface types default to point-to-point operation unless the multipoint keyword is used to configure a multipoint ATM or Frame Relay connection.

Multipoint Network Types

Figure 3.2 illustrates a typical multipoint connection that connects r3 to r4 and r5 over a Frame Relay network in a star topology. The lack of a virtual circuit connection between r4 and r5 differentiates this multipoint topology from a fully meshed NBMA topology.

Figure 3.2: Multipoint OSPF network

To correctly configure OSPF for this application, the operator must include the neighbor statement under each multipoint OSPF interface declaration. JUNOS software currently does not support automatic neighbor discovery. The use of the multipoint keyword in the so-0/2/0 interface configuration automatically enables point-to-multipoint OSPF operation so the OSPF network type does not require explicit setting in this example. The following code snippets correctly configure r3 for this multipoint OSPF application:

[edit] lab@r3# show interfaces so-0/2/0 no-keepalives; encapsulation frame-relay; unit 0 {     multipoint;     family inet {         address 10.1.0.3/24 {              multipoint-destination 10.1.0.4 dlci 400;              multipoint-destination 10.1.0.5 dlci 500;         }      } } [edit] lab@r3# show protocols ospf area 0.0.0.0 {      interface so-0/2/0.0 {          neighbor 10.1.0.4;          neighbor 10.1.0.5;      } } 

Use of the multipoint keyword requires the configuration of one or more neighbor statements to map remote IP addresses to local DLCI connection identifiers. Proper OSPF operation is determined using standard OSPF testing methodology, starting with the determination of r3's OSPF interface state:

[edit] lab@r3# run show ospf interface detail Interface              State     Area            DR ID           BDR ID       Nbrs so-0/2/0.0             PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         2 Type P2MP, address 10.1.0.3, mask 255.255.255.0, MTU 4470, cost 1 DR addr 0.0.0.0, BDR addr 0.0.0.0, adj count 2 Hello 10, Dead 40, ReXmit 5, Not Stub 

The highlighted fields in this capture confirm that r3's so-0/2/0.0 interface is considered by OSPF to be a point-to-multipoint interface. The empty DR and BDR fields are to be expected since the DR function is not present on multipoint network types. The neighbor count of 2 correctly reflects the neighbors that were manually configured on r3. We will now confirm r3's adjacency state, as shown next:

[edit] lab@r3# run show ospf neighbor   Address         Interface             State      ID              Pri  Dead 10.1.0.5         so-0/2/0.0             Full      10.0.3.5         128  38 10.1.0.4         so-0/2/0.0             Full      10.0.3.4         128  39

Based on the show ospf interface and show ospf neighbor displays, we can confirm that OSPF is correctly operating over this multipoint topology.

NBMA Network Types

Figure 3.3 illustrates a typical NBMA topology in which a full mesh of virtual circuit connections is provided between r3, r4, and r5. Even though this network will work fine using the default point-to-multipoint mode, it may be necessary to configure an NBMA network for interoper- ability with another vendor, to achieve maximum protocol efficiency for networks that meet the full mesh requirements of an NBMA, or to meet the specific configuration requirements for your examination scenario. When configured for NBMA operation, the OSPF protocol will endeavor to elect both a DR and BDR, in effect treating the WAN cloud as a LAN that happens to lack link-level broadcast.

Figure 3.3: NBMA OSPF topology

NBMA configuration is very similar to that of the multipoint case. The key differences relate to the inclusion of the eligible keyword after each neighbor that is considered capable of functioning as the DR, and the need to specify the network type as nbma. The poll-interval parameter is associated with NMBA networks, and functions to reduce the rate of hello packet transmission to neighbors that are assumed to be down. In essence, the hello interval is used to maintain adjacencies that are operational while the poll interval is used to solicit the formation of an adjacency with a neighbor that is currently marked as down. The default poll interval of 90 seconds has been left in place for this example. The OSPF configuration of all three of the nodes that form the OSPF NBMA topology are shown in Listings 3.1 through 3.3.

Listing 3.1: r3 OSPF Configuration

[edit] lab@r3# show protocols ospf area 0.0.0.0 {      interface so-0/2/0.0 {          interface-type nbma;          neighbor 10.1.0.4 eligible;          neighbor 10.1.0.5;      } }

Listing 3.2: r4 OSPF Configuration

[edit] lab@r4# show protocols ospf area 0.0.0.0 {      interface so-0/1/0.0 {          interface-type nbma;          neighbor 10.1.0.3 eligible;          neighbor 10.1.0.5;      } }

Listing 3.3: r5 OSPF Configuration

[edit] lab@r5# show protocols ospf area 0.0.0.0 {      interface so-1/0/0.0 {          interface-type nbma;         priority 0;          neighbor 10.1.0.3;          neighbor 10.1.0.4;      } } 

In this example, r3 and r4 have defined each other as being DR-eligible while r5 has been left in the default state of ineligible. To ensure operational consistency, r5 should have its local DR priority set to 0, as highlighted in the previous capture, so that it does not try to elect itself the DR for the NBMA network. r5's neighbor statements do not require the eligible keyword because its presence affects only the hello generation behavior of a router that considers itself to be DR-eligible.

It must be stressed that the eligible tag does not really affect a router's ability to become the DR, so much as to control the exchange of hello packets among a subset of routers that could be elected as the DR. Once elected as the DR, that router must send hello packets to all neighbors, whether they are listed as DR-eligible or not.

The net result of this configuration, and the rules that govern OSPF operation over an NBMA network, will therefore be:

1. r5 can never be the DR because it has a priority of 0.

2. Upon network activation, r3 and r4 will exchange hello packets for the purposes of electing a DR.

3. Once a DR is elected, the DR router will send hellos to all listed neighbors, which includes r5. r5 must in turn generate hello packets in response to the receipt of a hello packet from any node that considers itself to be the DR or BDR.

This behavior guarantees hellos will be exchanged between any two eligible routers-as is necessary for the proper functioning of the OSPF DR election algorithm-and that the total volume of hello packets can be dramatically reduced on a large NBMA topology by limiting the number of DR-eligible routers to a small subset of the total router population.

Who Uses This NBMA Stuff Anyway?

From a purely practical perspective, the fact that most ATM and Frame Relay topologies are configured to provide less than a full mesh of connectivity, coupled with the increased link speed of modern broadband access technologies, makes the whole motivation for NBMA support somewhat moot. Many industry gurus believe that VC-based WAN backbones should always be configured as a collection of point-to-point links or as a point-to-multipoint network. You should be prepared to configure all OSPF network types, popular or not, as part of your lab scenario.

Based on the rules that govern OSPF operation over NBMA networks and the current state of configuration in our example, we expect to find that r3 will have adjacencies to both r4 and r5, and that r3 will be functioning as either the DR or BDR based on the results of the DR election algorithm. Proper operation is verified with the following commands, starting with the determination that we have the proper NBMA interface configuration:

 [edit] lab@r3# run show ospf interface extensive Interface              State     Area            DR ID           BDR ID       Nbrs so-0/2/0.0             DR       0.0.0.0         10.0.3.3        10.0.3.4        2 Type NBMA, address 10.1.0.3, mask 255.255.255.0, MTU 4470, cost 1 DR addr 10.1.0.3, BDR addr 10.1.0.4, adj count 2, priority 128 Hello 30, Poll 90, Dead 120, ReXmit 5, Not Stub

The highlights in the previous capture confirm that r3's OSPF interface correctly shows the NBMA network type, and also confirms the election of a DR and BDR for the NBMA topology. Other fields in this display show the default settings for the priority, hello, and poll timer parameters; these values should be contrasted to the default settings for broadcast, point-to-point, and multipoint network types. Proper adjacency formation and additional DR election functionality is verified with the following command:

[edit] lab@r3# run show ospf neighbor detail   Address         Interface             State      ID              Pri  Dead 10.1.0.5         so-0/2/0.0             Full      10.0.3.5         0    118   area 0.0.0.0, opt 0x0, DR 10.0.1.3, BDR 10.0.1.4 10.1.0.4         so-0/2/0.0             Full      10.0.3.4         128  118   area 0.0.0.0, opt 0x42, DR 10.1.0.3, BDR 10.1.0.4   Up 00:02:13, adjacent 00:00:49

Because r5 is not listed as a DR-eligible neighbor, its DR priority setting should be set to 0, and this is confirmed in the highlighted portions of the previous capture. The DR priority is configured under the NBMA interface, and is used to influence the outcome of the DR election process. The following command will ensure that r4 will win a DR election contest should it be pitted against r3:

[edit protocols ospf area 0.0.0.0] lab@r4# set interface so-0/1/0.0 priority 200 

The DR function in OSPF is not preemptive. Therefore, even with its higher priority setting, r4 will not be able to "overthrow" r3 as the DR if r3 is already functioning in that capacity, which means that the first router to boot will tend to be the DR as long as it does not have a priority setting of 0. The DR priority setting would come into play if network connectivity were to be restored between r3 and r4 after being disrupted long enough for both routers to have elected themselves as the DR for the 10.1.0.0/24 subnet. Because there can be only one DR, the router with the lower priority will defer to the higher priority router in this case.

After committing this change and restarting the routing daemon on both r4 and r5, we wait for the DR election algorithm to complete, and then confirm that the results are as expected:

 [edit protocols ospf area 0.0.0.0] lab@r3# run show ospf neighbor detail   Address         Interface             State      ID              Pri  Dead 10.1.0.4         so-0/2/0.0             Full      10.0.3.4         200    110   area 0.0.0.0, opt 0x42, DR 10.1.0.4, BDR 10.1.0.3   Up 00:01:02, adjacent 00:01:02 . . .

The results shown confirm that r4 has won the DR election contest, and also display r5's modified DR priority setting.

Troubleshooting Network Type Problems

As previously mentioned, incorrect network type settings will normally result in OSPF adjacency failures. The following trace configuration and the resulting output, which was taken from r3, illustrate symptoms that are typically associated with incompatible network type settings. These captures are based on the topology shown in Figure 3.4.

Figure 3.4: Incorrect OSPF network types

 [edit protocols ospf] lab@r3# show traceoptions {     file ospf;      flag hello detail;      flag error detail; } area 0.0.0.0 {     interface so-0/2/0.0; }

The trace configuration is committed on r3, and you monitor the results:

[edit protocols ospf] lab@r3# run monitor start ospf [edit protocols ospf] lab@r3# *** ospf *** . . . Apr 24 15:05:09 OSPF sent Hello -> 224.0.0.5 (so-0/2/0.0) Apr 24 15:05:09   Version 2, length 44, ID 10.0.3.3, area 0.0.0.0 Apr 24 15:05:09    checksum 0xef1c, authtype 0 Apr 24 15:05:09   mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 128 Apr 24 15:05:09    dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Apr 24 15:05:19 OSPF sent Hello -> 224.0.0.5 (so-0/2/0.0) Apr 24 15:05:19   Version 2, length 44, ID 10.0.3.3, area 0.0.0.0 Apr 24 15:05:19    checksum 0xef1c, authtype 0 Apr 24 15:05:19   mask 255.255.255.0, hello_ivl 10 , opts 0x2, prio 128 Apr 24 15:05:19    dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Apr 24 15:05:22 OSPF rcvd Hello 10.1.0.4 -> 10.1.0.3 (so-0/2/0.0) Apr 24 15:05:22   Version 2, length 44, ID 10.0.3.4, area 0.0.0.0 Apr 24 15:05:22    checksum 0xe4b2, authtype 0 Apr 24 15:05:22   mask 255.255.255.0, hello_ivl 30 , opts 0x2, prio 128 Apr 24 15:05:22   dead_ivl 120, DR 10.1.0.4, BDR 0.0.0.0 Apr 24 15:05:22 OSPF packet ignored: hello interval mismatch 30 from 10.1.0.4 

The trace output shows that r3 is generating hellos with a 10-second interval as expected for the default point-to-point OSPF network type, while r4, which is set for NBMA operation, is sending hellos with a 30-second interval. The last line of the trace output clearly indicates that r3 scoffs at r4's hello parameters as it complains of the timer mismatch. The most obvious symptom of this network type incompatibility is the lack of neighbor detection and adjacency formation, as highlighted next:

[edit protocols ospf] lab@r3# run show ospf neighbor [edit protocols ospf] lab@r3# run show ospf interface Interface            State     Area            DR ID           BDR ID       Nbrs so-0/2/0.0           PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         0