Note: You must perform Lab0 for loading the initial configurations before starting this lab.
● Configure OSPF in area 0 over DMVPN cloud and on VLAN 146.
✓ Use a broadcast OSPF network type.
● Advertise Loopback0 prefixes into area 0, on routers R1 - R6.
● Configure DMVPN routers to ensure that R5 is elected as the DR.
● Configure routers on VLAN 146 so that:
✓ R6 is preferred to become the DR on the segment.
✓ If R6 goes down, R1 takes over the DR role.
✓ R4 does not participate in the DR election process.
Configurations
R1 - R4:
!
enable configure terminal
!
interface Tunnel0 ip ospf 1 area 0 ip ospf priority 0 ip ospf network broadcast
!
interface Loopback0 ip ospf 1 area 0
!
end
!
write
!
R1:
!
enable configure terminal
!
interface GigabitEthernet0/2 ip ospf 1 area 0 ip ospf priority 254
!
end
!
write
!
R4:
!
enable configure terminal
!
interface GigabitEthernet0/2 ip ospf 1 area 0 ip ospf priority 0
!
end
!
write
!
R6:
!
enable
configure terminal
!
interface GigabitEthernet0/0 ip ospf 1 area 0 ip ospf priority 255
!
interface Loopback0 ip ospf 1 area 0
!
end
!
write
!
R5:
!
enable configure terminal
!
interface Tunnel0 ip ospf 1 area 0 ip ospf network broadcast
!
interface Loopback0 ip ospf 1 area 0
!
end
!
write
!
Verifications
The OSPF DR/BDR election is determined based on the interface-level OSPF priority value along with the router-id. The device with the highest priority is elected the DR, and the device with the second-highest priority is elected the BDR. If there is a tie in the priority value, the device with the higher router-id is elected the DR, and the device with second-highest router-id the BDR. However, in certain designs the election may become unpredictable. DR/BDR election takes place only for OSPF network types of broadcast and non-broadcast.
This unpredictability is caused by the fact that the OSPF DR/BDR election does not support preemption like IS-IS does for its DIS election. Preemption means that if a new device comes onto the segment with a higher priority or router-id, it can take the DR/BDR status away from the current device.
Because OSPF does not support this, new devices must wait for a failure of the DR or BDR before the next election occurs. Additionally, the order in which the routers load their OSPF process will influence the election; basically, a router starts sending HELLO packets on the segment, and if no other OSPF routers are detected on the segment to negotiate the DR/BDR roles within the WAIT timer, the router declares itself as the DR. The WAIT timer is not directly configurable but always equals in value with the DEAD interval.
In the below case on the LAN segment of VLAN 146, R1, R4, and R6 compete for the DR/BDR election. Without priorities being configured, R6 will become the DR and R4 the BDR, based on the IP addresses of their Loopback0 interfaces.
This is based on the fact that the default interface priority is 1, and therefore if all three routers load the OSPF process at the same time, R6 wins the election.
By changing R6’s interface-level priority to 255, it is most likely to be elected the DR, and changing R4’s priority to 0 means it can never be elected the DR or BDR. R6’s show ip ospf neighbor and show ip ospf interface output indicate that R6 is the DR with a priority of 255, R1 is the BDR with a priority of 254, and R4 is a DROTHER because it has a priority of 0. Also note the WAIT timer value.
Adjacent with neighbor 170.1.1.1 (Backup Designated Router)
Adjacent with neighbor 170.1.4.4
Suppress hello for 0 neighbor(s)
R4#show ip ospf interface gigabitEthernet0/2 | i Priority
Transmit Delay is 1 sec, State DROTHER, Priority 0
R1#show ip ospf interface gigabitEthernet0/2 | i Priority
Transmit Delay is 1 sec, State BDR, Priority 254
R6’s link to VLAN 146 goes down. After R1's and R4’s dead timer expires, a new DR/BDR election occurs. When R1 detects this event, it asks all other neighbors on the segment to perform a new election. Because R4’s priority is 0, it does not send a response back to R1. The result is that R1 is promoted from the BDR status to the DR, but there is no new BDR elected.
R6#configure terminal
R6(config)#interface GigabitEthernet0/0
R6(config-subif)#shutdown
R1#debug ip ospf adj
OSPF adjacency debugging is on
R1#
OSPF-1 ADJ Gi0/2: 170.1.6.6 address 177.1.146.6 is dead
OSPF-1 ADJ Gi0/2: 170.1.6.6 address 177.1.146.6 is dead, state DOWN
%OSPF-5-ADJCHG: Process 1, Nbr 170.1.6.6 on GigabitEthernet0/2 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
OSPF-1 ADJ Gi0/2: Neighbor change event
OSPF-1 ADJ Gi0/2: DR/BDR election
OSPF-1 ADJ Gi0/2: Elect BDR 170.1.1.1
OSPF-1 ADJ Gi0/2: Elect DR 170.1.1.1
OSPF-1 ADJ Gi0/2: Elect BDR 0.0.0.0
OSPF-1 ADJ Gi0/2: Elect DR 170.1.1.1
OSPF-1 ADJ Gi0/2: DR: 170.1.1.1 (Id)
OSPF-1 ADJ Gi0/2: BDR: none
OSPF-1 ADJ Gi0/2: Remember old DR 170.1.6.6 (id)
R1#
OSPF-1 ADJ Gi0/2: Neighbor change event
OSPF-1 ADJ Gi0/2: DR/BDR election
OSPF-1 ADJ Gi0/2: Elect BDR 0.0.0.0
OSPF-1 ADJ Gi0/2: Elect DR 170.1.1.1
OSPF-1 ADJ Gi0/2: DR: 170.1.1.1 (Id)
OSPF-1 ADJ Gi0/2: BDR: none
OSPF-1 ADJ Gi0/2: Neighbor change event
OSPF-1 ADJ Gi0/2: DR/BDR election
OSPF-1 ADJ Gi0/2: Elect BDR 0.0.0.0
OSPF-1 ADJ Gi0/2: Elect DR 170.1.1.1
OSPF-1 ADJ Gi0/2: DR: 170.1.1.1 (Id)
OSPF-1 ADJ Gi0/2: BDR: none
This can also be verified by the show ip ospf neighbor or show ip ospf interface output on R1 or R4. R1 sees R4 as a neighbor with a priority of 0, therefore it is a DROTHER.
Adjacent with neighbor 170.1.1.1 (Designated Router)
Suppress hello for 0 neighbor(s)
When R6’s connection to VLAN 146 comes back up, R1 learns about the neighbor and a new election occurs. However, because there is no preemption for the DR election, R6 can only be elected the BDR, even though its priority is higher than R1's.
Adjacent with neighbor 170.1.6.6 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
For LAN segments such as VLAN 146, it technically does not matter which device is the DR or the BDR, because everyone has direct Layer 2 connectivity with each other. The only design issue of the DR/BDR placement in this case is a function of the memory and CPU resources of the DR/BDR and how many neighbors are on the segment. On the DMVPN network between R1, R2, R3, R4, and R5, R5 needs to be the DR so that proper LSA exchange takes place.
This is because all OSPF routers reach the OSPF FULL state only with the DR and BDR, and remain in the TWO-WAY state with all other neighbors on the segment, thus exchange LSAs only with DR/BDR. Because OSPF packets are not functional between spokes, if one spoke becomes the DR, as only the DR floods LSA's on the segment, the OSPF database will be broken and the routing table incomplete. The priority of all spokes has been lowered to zero so that they cannot become DR, regardless of which routers are first configured on the segment.
Let's leave the spoke with the default priority of one (interface tunnel0 - ip ospf priority 1) and disable R5's Tunnel0 interface. After the DEAD interval expires, all spokes will declare R5 as DOWN and start DR/BDR election. Basically, all spokes will become DRs, because HELLO packets are not exchanged between spokes, so there is no negotiation.
R5#configure terminal
R5(config)#interface Tunnel0
R5(config-if)#shutdown
R1#show ip ospf interface tunnel0 | i Desig|State|backup
The problem in this design occurs when R5 tries to come back onto the segment. As R5 receives OSPF HELLO packets from all spokes, all claiming to be DRs with the same interface priority, it will finally elect R4 as the DR based on its highest router-ID and itself as the BDR.
R5#debug ip ospf adj
R5#configure terminal
R5(config)#interface Tunnel0
R5(config-if)#no shutdown
OSPF-1 ADJ Tu0: Route adjust notification: UP/UP
OSPF-1 ADJ Tu0: Interface going Up
OSPF-1 ADJ Tu0: Interface state change to UP, new ospf state WAIT
OSPF-1 ADJ Tu0: 2 Way Communication to 170.1.2.2, state 2WAY
OSPF-1 ADJ Tu0: Rcv DBD from 170.1.2.2 seq 0xB98 opt 0x52 flag 0x7 len 32 mtu 1400 state 2WAY
OSPF-1 ADJ Tu0: Nbr state is 2WAY
OSPF-1 ADJ Tu0: 2 Way Communication to 170.1.1.1, state 2WAY
OSPF-1 ADJ Tu0: Backup seen event before WAIT timer
Because of the desired function of the DR, the network design is now broken. For example, for R2 to advertise its Loopback0, the LSA Type-1 update must be sent to the DR and BDR, but only the DR can relay the LSA further to the neighbors on the segment. However, R2 does not have an OSPF relation with R4, which is the DR.
The result is that LSA Type-1 replication in the DMVPN cloud is now incomplete, and different routers end up with different views of the topology, basically missing parts of it. Based on this inconsistency of information, SPF is not uniform, and some routers have reachability to some segments whereas others do not. The result of this can be seen in either the OSPF database or the routing tables of the devices in question. Verify that R2's Loopback0 is present in the OSPF database of the BDR (R5), and possibly in the OSPF database of the DR (R4) if the entry did not expire from when it was advertised by the old DR (R5), and is not present in the routing table of either routers.
R5#show ip ospf database router adv-router 170.1.2.2
OSPF Router with ID (177.1.5.5) (Process ID 1)
Router Link States (Area 0)
Adv Router is not-reachable in topology Base with MTID 0
LS age: 540
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 170.1.2.2
Advertising Router: 170.1.2.2
LS Seq Number: 80000015
Checksum: 0x5357
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 170.1.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 177.1.0.2
(Link Data) Router Interface address: 177.1.0.2
Number of MTID metrics: 0
TOS 0 Metrics: 1000
R5#show ip route 170.1.2.2
% Subnet not in table
R4#show ip ospf database router adv-router 170.1.2.2
OSPF Router with ID (170.1.4.4) (Process ID 1)
Router Link States (Area 0)
Adv Router is not-reachable in topology Base with MTID 0
LS age: 614
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 170.1.2.2
Advertising Router: 170.1.2.2
LS Seq Number: 80000015
Checksum: 0x5357
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 170.1.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 177.1.0.2
(Link Data) Router Interface address: 177.1.0.2
Number of MTID metrics: 0
TOS 0 Metrics: 1000
R4#show ip route 170.1.2.2
% Subnet not in table
The incomplete database view of the routers is clear through the message Adv Router is not-reachable in topology Base from the above outputs. This means that the DR of the segment, which now is R4, did not advertise in its LSA Type-2 that R2 is a router on the segment, and this is because R2 is not OSPF neighbors with R4.
R4#show ip ospf database network adv-router 170.1.4.4
OSPF Router with ID (170.1.4.4) (Process ID 1)
Net Link States (Area 0)
LS age: 942
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 177.1.0.4 (address of Designated Router)
Advertising Router: 170.1.4.4
LS Seq Number: 80000001
Checksum: 0x5E01
Length: 32
Network Mask: /24
Attached Router: 170.1.4.4
Attached Router: 177.1.5.5
Because R5 is the only router that has OSPF adjacency with the DR (R4), R4 and R5 will install a route for each other's Loopback0 prefixes, because the OSPF database is complete for LSA Type-1 generated by these routers.
R5#show ip route 170.1.4.4
Routing entry for 170.1.4.4/32
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 177.1.0.4 on Tunnel0, 00:17:50 ago
Routing Descriptor Blocks:
* 177.1.0.4, from 170.1.4.4, 00:17:50 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
R4#show ip route 170.1.5.5
Routing entry for 170.1.5.5/32
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 177.1.0.5 on Tunnel0, 00:18:01 ago
Routing Descriptor Blocks:
* 177.1.0.5, from 177.1.5.5, 00:18:01 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
The process continues as such depending on where the OSPF topology is viewed from. Therefore, at this point in the configuration, the network design works in some cases but not all cases. To ensure that the network works in all cases, we must guarantee that R5 is always elected the DR. This is because R5 is the only neighbor that can form a direct adjacency with all other devices in the DMVPN cloud. The logic of the solution, in this particular case, is somewhat backward because of how OSPF deals with preemption. Even if R5 is configured with a priority value of 255, it cannot preempt whichever router elected itself as the DR after it went down.
The only thing R5 can do is re-elect itself as the BDR. Therefore, instead of trying to prefer that R5 become the DR by raising its interface priority to maximum, we must ensure that R1, R2, R3, and R4 are not elected the DR. This is accomplished by configuring the OSPF priority value as 0 at the interface level of each of these devices. Because priority 0 means they will not participate in the election, R5 is the only candidate that can be elected the DR and, additionally, no one is eligible to be elected the BDR. If R5 goes down, all routing information is lost, but when R5 comes back it is fully restored. Verification of this can be seen in the show ip ospf neighbor output on R5. With the remote devices configured with priority 0, R5 is elected the DR, and all other devices revert back to DROTHERs.
When the correct configuration is complete, it can also be verified by the show ip ospf database output. Only the DR on an OSPF segment originates the Network LSA (LSA 2). The Network LSA is used to describe all the neighbors that the DR on the segment is adjacent with to the BDR and DROTHERs on that link.
R5#show ip ospf database network adv-router 170.1.5.5
Verify the LSA Type-1 generated by any routers on the DMVPN cloud; note that for the DMVPN segment where DR/BDR election takes place, the network masks is not advertised, the network mask being advertised by the DR in LSA Type-2.
R5#show ip ospf database router adv-router 170.1.5.5
Verify that now, when DR election is correct, OSPF-enabled interfaces are advertised and learned, and therefore prefixes appear in the routing table.
R5#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
170.1.0.0/32 is subnetted, 6 subnets
O 170.1.1.1 [110/1001] via 177.1.0.1, 00:04:20, Tunnel0
O 170.1.2.2 [110/1001] via 177.1.0.2, 00:04:20, Tunnel0
O 170.1.3.3 [110/1001] via 177.1.0.3, 00:04:20, Tunnel0
O 170.1.4.4 [110/1001] via 177.1.0.4, 00:25:01, Tunnel0
O 170.1.6.6 [110/1002] via 177.1.0.4, 00:25:01, Tunnel0
[110/1002] via 177.1.0.1, 00:04:20, Tunnel0
177.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
O 177.1.146.0/24 [110/1001] via 177.1.0.4, 00:25:01, Tunnel0
[110/1001] via 177.1.0.1, 00:04:20, Tunnel0
R2#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
170.1.0.0/32 is subnetted, 6 subnets
O 170.1.1.1 [110/1001] via 177.1.0.1, 00:11:11, Tunnel0
O 170.1.3.3 [110/1001] via 177.1.0.3, 00:11:11, Tunnel0
O 170.1.4.4 [110/1001] via 177.1.0.4, 00:11:11, Tunnel0
O 170.1.5.5 [110/1001] via 177.1.0.5, 00:11:11, Tunnel0
O 170.1.6.6 [110/1002] via 177.1.0.4, 00:11:11, Tunnel0
[110/1002] via 177.1.0.1, 00:11:11, Tunnel0
177.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O 177.1.146.0/24 [110/1001] via 177.1.0.4, 00:11:11, Tunnel0
