Note: You must perform Lab 0 for loading the initial configurations before starting this lab.
● Configure OSPF area 0 on R1, R2, R3, R4, and R5’s connection to the DMVPN network:
✓ Use process ID of 1.
✓ Advertise Loopback0 prefixes of R1 - R2 into area 0.
✓ Advertise Loopback0 prefixes of R3 - R4 into area X, where X is the router number.
✓ Use a single network command on the DMVPN hub, which is R5.
✓ Use only interface-level commands on the DMVPN spokes.
● Change the default OSPF network type to non-broadcast.
● Ensure that you have IP connectivity between Loopback0 prefixes of the DMVPN routers.
Configurations
R1 - R2:
! enable configure terminal ! interface Tunnel0 ip ospf 1 area 0 ip ospf network non-broadcast ip ospf priority 0 ! interface Loopback0 ip ospf 1 area 0 ! end ! write !
R3:
! enable configure terminal ! interface Tunnel0 ip ospf 1 area 0 ip ospf network non-broadcast ip ospf priority 0
!
interface Loopback0 ip ospf 1 area 3
!
end
!
write
!
R4:
!
enable configure terminal
!
interface Tunnel0 ip ospf 1 area 0 ip ospf network non-broadcast ip ospf priority 0
!
interface Loopback0 ip ospf 1 area 4
!
end
!
write
!
In this solution, OSPF is enabled on spokes with the interface-level ip ospf command. The network statement could have also been used under the OSPF process, but this is used only on the hub. To enable OSPF on the hub on both Loopback0 and Tunnel0, a very generic network command was used, which basically enabled OSPF on all interfaces in area 0. Although not specifically asked by the task, using a OSPF network-type of non-broadcast implies there will be DR/BDR election, and since DR/BDR needs to be adjaccent with all other OSPF enabled routers on the segment, it means the DR needs to be the hub; the only way to ensure that is to configure the spokes with an OSPF priority of 0, which will disable DR/BDR participation on it.
R5#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 170.1.5.5/32 1 LOOP 0/0
Lo5 1 0 177.1.5.5/24 1 LOOP 0/0
Tu0 1 0 177.1.0.5/24 1000 DR 4/4
NV0 1 0 Unnumbered Gi0/0 1785 P2P 0/0
Gi0/2 1 0 177.1.58.5/24 1 DR 0/0
Gi0/1 1 0 177.1.45.5/24 1 DR 0/0
Gi0/0 1 0 169.254.100.5/24 1 DR 0/0
Verify also on spokes that OSPF is enabled in area 0:
R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 170.1.1.1/32 1 LOOP 0/0
Tu0 1 0 177.1.0.1/24 1000 DROTH 1/1
R2#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 170.1.2.2/32 1 LOOP 0/0
Tu0 1 0 177.1.0.2/24 1000 DROTH 1/1
R3#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Tu0 1 0 177.1.0.3/24 1000 DROTH 1/1
Lo0 1 3 170.1.3.3/32 1 LOOP 0/0
R4#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Tu0 1 0 177.1.0.4/24 1000 DROTH 1/1
Lo0 1 4 170.1.4.4/32 1 LOOP 0/0
The default OSPF network types on the DMVPN interface (which is an mGRE interface) is Point-to-Point, however in our configuration we have changed it to non-broadcast as seen from the show ip ospf interface output below.
R1#show ip ospf interface tunnel 0
Tunnel0 is up, line protocol is up
Internet Address 177.1.0.1/24, Area 0, Attached via Interface Enable
Process ID 1, Router ID 170.1.1.1, Network Type NON_BROADCAST, Cost: 1000
Topology-MTID Cost Disabled Shutdown Topology Name
0 1000 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State DROTHER, Priority 0
Adjacent with neighbor 177.1.5.5 (Designated Router)
Suppress hello for 0 neighbor(s)
The Non-Broadcast network type means that there will be a DR/BDR election, and that hellos are exchanged as unicast. To unicast OSPF hellos, the neighbor statement must be configured under the OSPF process of the DR. When the DROTHERs and/or BDR hear the unicast hellos from the DR, they will automatically respond back with their own unicast hellos.
This implies that the neighbor statement can be configured everywhere, but is only required on the DR. As within the DMVPN cloud, OSPF packets are only between hub and spokes (not between spokes); R5 needs to be the DR. When R5 is configured with the neighbor statement, the show ip ospf neighbor output should be checked to verify adjacency. R1, R2, R3, and R4 are the spokes for this DMVPN cloud. They will see themselves as either BDR or DROTHER because they do not see each other's OSPF Hello Packets.
When adjacency is established in area 0, Inter-Area routing advertisements can be propagated throughout the entire topology. This is because R1, R2, R3, R4, and R5 are now ABRs and can originate the Network Summary LSA (LSA 3) describing Inter-Area routes to the other neighbors in their attached areas. From the show ip ospf database output on R5, the Summary Net link States (Area 0) shows ABRs that are advertising information from other areas into area 0. In this case, R3 and R4 are advertising their Loopbacks; note that R5 does not know the area these prefixes were injected into.
R5#show ip ospf database
OSPF Router with ID (177.1.5.5) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
170.1.1.1 170.1.1.1 1047 0x80000003 0x00AE12 2
170.1.2.2 170.1.2.2 1047 0x80000003 0x00B9FF 2
170.1.3.3 170.1.3.3 923 0x80000004 0x00343F 1
170.1.4.4 170.1.4.4 1047 0x80000003 0x00224D 1
177.1.5.5 177.1.5.5 1018 0x80000008 0x008234 6
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
177.1.0.5 177.1.5.5 1046 0x80000001 0x007BBE
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
170.1.3.3 170.1.3.3 1234 0x80000001 0x006E6A
170.1.4.4 170.1.4.4 1218 0x80000001 0x004C88
R5#show ip ospf database summary
OSPF Router with ID (177.1.5.5) (Process ID 1)
Summary Net Link States (Area 0)
LS age: 1250
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 170.1.3.3 (summary Network Number)
Advertising Router: 170.1.3.3
LS Seq Number: 80000001
Checksum: 0x6E6A
Length: 28
Network Mask: /32
MTID: 0 Metric: 1
LS age: 1234
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 170.1.4.4 (summary Network Number)
Advertising Router: 170.1.4.4
LS Seq Number: 80000001
Checksum: 0x4C88
Length: 28
Network Mask: /32
MTID: 0 Metric: 1
As R3 and R4 are connected to multiple areas, both take all prefixes from area 0 LSA Type-1 and generate LSA Type-3 into areas 3 and 4, for example R3:
R3#show ip ospf database
OSPF Router with ID (170.1.3.3) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
170.1.1.1 170.1.1.1 1095 0x80000003 0x00AE12 2
170.1.2.2 170.1.2.2 1095 0x80000003 0x00B9FF 2
170.1.3.3 170.1.3.3 970 0x80000004 0x00343F 1
170.1.4.4 170.1.4.4 1095 0x80000003 0x00224D 1
177.1.5.5 177.1.5.5 1067 0x80000008 0x008234 6
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
177.1.0.5 177.1.5.5 1095 0x80000001 0x007BBE
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
170.1.3.3 170.1.3.3 1281 0x80000001 0x006E6A
170.1.4.4 170.1.4.4 1266 0x80000001 0x004C88
Router Link States (Area 3)
Link ID ADV Router Age Seq# Checksum Link count
170.1.3.3 170.1.3.3 970 0x80000002 0x00C258 1
Summary Net Link States (Area 3)
Link ID ADV Router Age Seq# Checksum
169.254.100.0 170.1.3.3 1089 0x80000001 0x00B6DA
170.1.1.1 170.1.3.3 1079 0x80000001 0x00CC24
170.1.2.2 170.1.3.3 1079 0x80000001 0x00B737
170.1.4.4 170.1.3.3 1079 0x80000001 0x008D5D
170.1.5.5 170.1.3.3 1089 0x80000001 0x007870
177.1.0.0 170.1.3.3 1281 0x80000001 0x007C70
177.1.5.5 170.1.3.3 1089 0x80000001 0x001DC4
177.1.45.0 170.1.3.3 1089 0x80000001 0x009529
177.1.58.0 170.1.3.3 1089 0x80000001 0x0006AB
The result of the Inter-Area routing advertisements can be seen in the routing table via the show ip route ospf output. These new routes are denoted as O IA for OSPF Inter-Area. The next important design issue in this example is how the DR processes routing advertisements over the DMVPN cloud. There is no direct adjacency between spoke routers, because regardless of the DMVPN Phase being configured, IGP packets are not sent between spokes (although with certain configurations this can be achieved, there is no reason for doing it). If you reached this step and R5 is not the DR for the segment, an additional problem will be seen that is covered in the next section regarding the DR/BDR election process. However, for the sake of this example, let’s assume that R5 is the DR.
The DR state on the segment means that R5 is responsible for replicating LSA information between its adjacent neighbors. For example, R3 sends R5 the LSA type-3 route 170.1.3.3/24 describing its Loopback0 prefix. When R4 or any other spoke learns this over the DMVPN cloud it comes from the DR, R5, but the next-hop value of the route is 177.1.0.3, the originator of the LSA type-3 advertisement.
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, 5 subnets
O 170.1.1.1 [110/1001] via 177.1.0.1, 00:19:13, Tunnel0
O 170.1.2.2 [110/1001] via 177.1.0.2, 00:19:13, Tunnel0
O IA 170.1.3.3 [110/1001] via 177.1.0.3, 00:19:13, Tunnel0
O IA 170.1.4.4 [110/1001] via 177.1.0.4, 00:19:13, Tunnel0
R4#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, 5 subnets
O 170.1.1.1 [110/1001] via 177.1.0.1, 00:19:19, Tunnel0
O 170.1.2.2 [110/1001] via 177.1.0.2, 00:19:19, Tunnel0
O IA 170.1.3.3 [110/1001] via 177.1.0.3, 00:19:19, Tunnel0
O 170.1.5.5 [110/1001] via 177.1.0.5, 00:19:29, Tunnel0
177.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 177.1.5.5/32 [110/1001] via 177.1.0.5, 00:19:29, Tunnel0
O 177.1.58.0/24 [110/1001] via 177.1.0.5, 00:19:29, Tunnel0
This is because the DR passes the routes along, but it does not modify any of the routing lookup attributes. The result of this behavior is seen when route recursion is performed to the final destination. From the IP Routing section of this workbook, recall that when a routing lookup is done, the router must also perform layer 3 to layer 2 mapping for the next-hop value on the link. Let’s look at what happens when R4 tries to send traffic to 170.1.5.5. First, R4 finds the longest match to 170.1.5.5, which is 170.1.5.5/32 via the next-hop 177.1.0.5.
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:19:57 ago
Routing Descriptor Blocks:
* 177.1.0.5, from 177.1.5.5, 00:19:57 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
R4 then must do another recursive lookup to find out how to forward toward 177.1.0.5. This is seen via the match 177.1.0.0/24 out Tunnel0.
R4# show ip route 177.1.0.5
Routing entry for 177.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
Because Tunnel0 is a DMVPN tunnel interface (mGRE), R4 must now determine the NBMA address of the next-hop through NHRP, which was statically defined in the initial configs. In this case, as the NBMA addresses of all routers share the same VLAN, R4 will also need the ARP entry for R5's NBMA. In this case, the layer 3 routing lookup is successful, and the layer 2 resolution is successful. The result is a successful ICMP PING to the destination.
R4#show ip nhrp 177.1.0.5
177.1.0.5/32 via 177.1.0.5
Tunnel0 created 00:27:55, never expire
Type: static, Flags: used
NBMA address: 169.254.100.5
R4#show ip arp 169.254.100.5
Protocol Address Age (min) Hardware Addr Type Interface
Internet 169.254.100.5 28 5006.0005.0000 ARPA GigabitEthernet0/0
R4#ping 170.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 170.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
All the above can be seen at the CEF and adjacency level, which is the data the router actually uses for forwarding.
path 0E10F09C, share 1/1, type attached nexthop, for IPv4
nexthop 177.1.0.5 Tunnel0, IP midchain out of Tunnel0, addr 177.1.0.5 10756500
output chain:
IP midchain out of Tunnel0, addr 177.1.0.5 10756500
IP adj out of GigabitEthernet0/0, addr 169.254.100.5 0E111160
R4#show adjacency 169.254.100.5 detail
Protocol Interface Address
IP GigabitEthernet0/0 169.254.100.5(10)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 1
Encap length 14
5006000500005006000400000800
ARP
For spoke-to-spoke traffic, the DMVPN Phase and the OSPF network type enabled determine how traffic will be routed finally (through the hub, or directly from spoke-to-spoke); initially, it is always routed via the hub. These aspects are discussed in the DMVPN section. So spoke-to-spoke traffic will always be functional with DMVPN, which is different than with the Frame Relay case, where a full-mesh of spoke-to-spoke DLCIs was required, or alternatively a full-mesh of frame-relay map statements through the hub was required, to obtain spoke-to-spoke connectivity in the data plane. This is because of the dynamic spoke-to-spoke provisioning behavior of DMVPN, as compared with the static spoke-to-spoke DLCI provisioning of Frame Relay.
