Designated Routers on WANs and OSPF Network Types

Using a DR makes good sense on a LAN because it improves LSA flooding efficiency. Likewise, not using a DR on a point-to-point WAN link also makes sense, because with only two routers on the subnet, there is no inefficiency upon which to improve. However, on nonbroadcast multiaccess (NBMA) networks, arguments can be made regarding whether a DR is helpful. So, OSPF includes several options that include a choice of whether to use a DR on WAN interfaces.

Cisco router interfaces can be configured to use, or not use, a DR, plus a couple of other key behaviors, based on the OSPF network type for each interface. The OSPF network type determines that router's behavior regarding the following:

KEY ■ Whether the router tries to elect a DR on that interface POINT

■ Whether the router must statically configure a neighbor (with the neighbor command), or find neighbors using the typical multicast Hello packets

■ Whether more than two neighbors should be allowed on the same subnet

For instance, LAN interfaces default to use an OSPF network type of broadcast. OSPF broadcast networks elect a DR, use Hellos to dynamically find neighbors, and allow more than two routers to be in the same subnet on that LAN. For HDLC and PPP links, OSPF uses a network type of point-to-point, meaning that no DR is elected, only two IP addresses are in the subnet, and neighbors can be found through Hellos.

Table 10-3 summarizes the OSPF interface types and their meanings. Note that the interface type values can be set with the ip ospf network type interface subcommand; the first column in the table lists the exact keyword according to this command. Also, for cases in which a DR is not elected, all routers that become neighbors also attempt to become adjacent by the direct exchange of DD, LSR, and LSU packets.

Table 10-3 OSPF Network Types

Table 10-3 OSPF Network Types

KEY POINT

Interface Type	Hello Command?	More than 2 Hosts Allowed in the Subnet?
Broadcast	Yes	10	No	Yes
Point-to-point1	No	10	No	No
Nonbroadcast2 (NBMA)	Yes	30	Yes	Yes
Point-to-multipoint	No	30	No	Yes
Point-to-multipoint nonbroadcast	No	30	Yes	Yes
Loopback	No	—	—	No

1 Default on Frame Relay point-to-point subinterfaces.

2 Default on Frame Relay physical and multipoint subinterfaces.

KEY POINT

1 Default on Frame Relay point-to-point subinterfaces.

2 Default on Frame Relay physical and multipoint subinterfaces.

Caveats Regarding OSPF Network Types over NBMA Networks

When configuring OSPF over Frame Relay, the OSPF network type concept can become a bit troublesome. In fact, many CCIE Routing and Switching lab preparation texts and lab books focus on the variety of combinations of OSPF network types used with Frame Relay for various interfaces/subinterfaces. The following list contains many of the key items you should check when looking at an OSPF configuration over Frame Relay, when the OSPF network types used on the various routers do not match:

■ Make sure the default Hello/Dead timers do not cause the Hello parameter check to fail. (See Table 10-3 for the defaults for each OSPF network type.)

■ If one router expects a DR to be elected, and the other does not, the neighbors may come up, and full LSAs be communicated. However, show command output may show odd information, and next-hop routers may not be reachable. So, make sure all routers in the same NBMA subnet use an OSPF network type that either does use a DR or does not.

■ If a DR is used, the DR and BDR must have a permanent virtual circuit (PVC) to each other router in the subnet. If not, not all routers will be able to learn routes, because the DR must forward the DD and LSU packets to each of the other routers. Routers without a PVC to each other router should be prevented from becoming a DR/BDR.

■ If one router requires a static neighbor command, typically the other router on the other end of the PVC does not require a neighbor command. For clarity, however, it is better to configure neighbor commands on both routers.

Two very simple options exist for making OSPF work over Frame Relay—both of which do not require a DR and do not require neighbor commands. If the design allows for the use of point-to-point subinterfaces, use those, take the default OSPF network type of point-to-point, and no additional work is required. If multipoint subinterfaces are needed, or if the configuration must not use subinterfaces, adding the ip ospf network point-to-multipoint command on all the routers works, without requiring additional effort to manually define neighbors or worry about which router becomes the DR.

Example of OSPF Network Types and NBMA

On NBMA networks with an OSPF network type that requires that a DR be elected, you must take care to make sure the correct DR is elected. The reason is that the DR and BDR must each have a PVC connecting it to all the DROther routers—otherwise, LSA flooding will not be possible. So, with partial meshes, the election should be influenced by configuring the routers' priority and RIDs such that the hub site of a hub-and-spoke partial mesh becomes the DR. Figure 10-3 shows an example network for which R1 should be the only router allowed to become DR or BDR.

Figure 10-3 Network Used in the Frame Relay Priority and Network Type Example

Figure 10-3 Network Used in the Frame Relay Priority and Network Type Example

Example 10-3 depicts the following scenarios relating to DR election in Figure 10-3:

■ The R1, R3, and R5 configuration is correct for operating with default OSPF network type nonbroadcast in a partial mesh.

■ R6 has omitted the ip ospf priority interface subcommand, causing it to inadvisably become the DR.

■ R4 will be used as an example of what not to do, in part to point out some interesting facts about OSPF show commands.

NOTE Figure 10-3 and Example 10-3 do not depict a suggested design for Frame Relay and OSPF. With this topology, using point-to-point subinterfaces in all cases, using four small (/30) subnets, and defaulting to OSPF network type point-to-point would work well. Such a design, however, would not require any thought regarding the OSPF network type. So, this example is purposefully designed to provide a backdrop from which to show how the OSPF network types work.

Example 10-3 shows only the nondefault OSPF configuration settings; also, the routers have an obvious RID numbering scheme (1.1.1.1 for R1, 2.2.2.2 for R2, and so on).

Example 10-3 Setting Priority on NBMA Networks

! R1 configuration — the neighbor commands default to a priority value of 0, ! meaning R1s perception of that neighbor is priority 0. router ospf 1 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0 neighbor 10.1.111.3 neighbor 10.1.111.4 neighbor 10.1.111.5 neighbor 10.1.111.6

! R3 configuration — R3's interface priority is set to 0; R1 will use the higher ! of R3's announced priority 0 (based on R3's ip ospf priority interface ! subcommand) and the priority value on R1's neighbor command, which defaulted ! to 0. So, R3 will not ever become a DR/BDR. interface Serial0/0.1 multipoint ip address 10.1.111.3 255.255.255.0 ip ospf priority 0 frame-relay interface-dlci 100

! R4 configuration — note from Figure 10-3 that R4 is using a point-to-point ! subinterface, with all defaults. This is not a typical use of a point-to-point ! subinterface, and is shown to make a few points later in the example. router ospf 1

network 0.0.0.0 255.255.255.255 area 0

! R5's configuration is equivalent to R3 in relation to the OSPF network type ! and its implications, interface Serial0.1 multipoint ip address 10.1.111.5 255.255.255.0 ip ospf priority 0 frame-relay interface-dlci 100

router ospf 1 network 0.0.0.0 255.255.255.255 area 0

! R6 configuration — R6 forgot to set the interface priority with the ip ospf ! priority 0 command, defaulting to priority 1. router ospf 1 network 0.0.0.0 255.255.255.255 area 0

! Below, the	results	of R6's default	interface	priority of	1 — R6	with RID
! 6.6.6.6, and an announced priority			of 1, wins	the DR election.		Note that the
! command is	issued	on R1.
R1# show ip	ospf neighbor
Neighbor ID	Pri	State	Dead Time	Address		Interface
6.6.6.6	1	FULL/DR	00:01:52	10.1.111	6	Serial0/0
3.3.3.3	0	FULL/DROTHER	00:01:46	10.1.111	3	Serial0/0
N/A	0	ATTEMPT/DROTHER	-	10.1.111	4	Serial0/0
5.5.5.5	0	FULL/DROTHER	00:01:47	10.1.111	5	Serial0/0

Next, R1s neighbor command was automatically changed to "priority 1" based on the Hello, with priority 1, that R1 received from R6. To prevent this dynamic reconfiguration, you could add an ip ospf priority 0 command under R6's s0/0.1 _interface.

R1# show run | beg router ospf 1 router ospf 1 network 0.0.0.0 255.255.255.255 area 0 neighbor 10.1.111.6 priority 1 neighbor 10.1.111.3 neighbor 10.1.111.4 neighbor 10.1.111.5 lines omitted for brevity

Below, R4 is OSPF network type "point to point," with Hello/dead of 10/40. R1s settings, based on Table 10-3, would be nonbroadcast, 30/120. R4# show ip ospf int s 0/0.1 Serial0/0.1 is up, line protocol is up Internet Address 10.1.111.4/24, Area 0

Process ID 1, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 1562 Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 lines omitted for brevity

Below, R4 changes its network type to yet a different value, one that expects neighbor commands, but does not expect a DR to be used. R4# conf t

Enter configuration commands, one per line. End with CNTL/Z. R4(config)# int s 0/0.1

R4(config-subif)# ip ospf network point-to-multipoint non-broadcast

! Next, R1 and R4 become neighbors now that the Hello parameters match. Note that ! R1 believes that R4 is DROther. R1# show ip ospf neighbor

Dead Time Address

Interface

Neighbor ID Pri State ! lines omitted for brevity

4.4.4.4 1 FULL/DROTHER 00:01:56 10.1.111.4 Serial0/0

! Below, R4 agrees it is in a full state with R1, but does not list R1 as DR, ! because R4 is not using the concept of a DR at all due to R4's network type. R4# sh ip ospf neigh

Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 0 FULL/ - 00:01:42 10.1.111.1 Serial0/0.1

The first and most important point from Example 10-3 is the actual behavior of the two ways to set the priority in the example. The Cisco IOS Configuration Guide at Cisco.com states that the OSPF neighbor command defines the priority of the neighbor. However, in practice, a router's neighbor priority setting is compared with the priority inside the Hello it receives from that neighbor— and the larger of the two values is used. In this example, R1's neighbor 10.1.111.6 command (with default priority of 0) was overridden by R6's Hello, which was based on R6's default OSPF interface priority of 1. So, during DR election, R1 and R6 tied on OSPF priority, and R6 won due to its larger (6.6.6.6 versus 1.1.1.1) RID. R1 even automatically changed its neighbor command dynamically to neighbor 10.1.111.6 priority 1 to reflect the correct priority for R6.

Also note that, although neighbors must be statically configured for some network types, the neighbor command needs to be configured on only one router. R3 and R5, with correct working configurations, did not actually need a neighbor command.

Finally, it might seem that all is now fine between R1 and R4 by the end of the example, but even though the neighbors are fully adjacent, R4 cannot route packets to R3, R5, or R6 over the Frame Relay network. For instance, R5 could have some routes that point to 10.1.111.4 (R4's Frame Relay IP address) as the next hop. However, because R5 is using a multipoint subinterface, R5 will not know what PVC to use to reach 10.1.111.4. (Chapter 7, "IP Forwarding (Routing)," covers how Frame Relay mapping occurs, and the logic used on multipoint and point-to-point subinterfaces.) In this case, the routers with multipoint subinterfaces would need to add frame-relay map commands; for example, R5 would need a frame-relay map ip 10.1.111.4 100 broadcast command, causing packets to next-hop 10.1.111.4 to go over DLCI 100 to R1, which would then route the packet on to R4. Keep in mind that R4's configuration is not a recommended configuration.

Continue reading here: SPF Calculation

Was this article helpful?

0 0