Previous posts Beginning routing design DMVPN & DMVPN

I'm still trying to figure out a good way to organize configurations used for the labs, that can also easily be shared. I'd like to avoid pasting a bunch of configuration into these posts, but for transparency of what's being done, I'll probably have to.

Hub redundancy

I'm going to configure dc2-r1 as hub2 and I have to add the second hub configuration to every spoke router. I've also corrected my static route to the internet.

hostname dc2-r1 ! interface e1/0 ip address 10.32.0.1 255.255.255.252 description link-dc2-r2 no shut ! interface e1/1 ip address 10.32.0.5 255.255.255.252 description link-dc2-r3 no shut ! router ospf 1 router-id 5.5.5.5 passive-interface default no passive-interface e1/0 no passive-interface e1/1 network 10.32.0.0 0.0.0.255 area 0 network 10.172.0.0 0.0.0.255 area 0 ! interface e2/0 description isp4-r1 ip address 100.0.0.26 255.255.255.252 no shut ! ip route 100.0.0.0 255.255.255.0 100.0.0.25 ! interface tunnel1 ip address 10.172.0.5 255.255.255.0 ip nhrp authentication lab1 ip nhrp map multicast dynamic ip nhrp network-id 1 ip nhrp holdtime 300 ip nhrp redirect tunnel source e2/0 tunnel mode gre multipoint ip ospf network broadcast _____________________________________________ hostname Spoke1 ! ip route 100.0.0.0 255.255.255.0 100.0.0.33 _____________________________________________ hostname Spoke2 ! ip route 100.0.0.0 255.255.255.0 100.0.0.17 _____________________________________________ hostname Spoke3 ! ip route 100.0.0.0 255.255.255.0 100.0.0.13

The second hub router doesn't have any function yet. The NHRP database is empty, because there is nothing sending requests to the router. Also, it doesn't send any requests either. Along with adding a second NHS on every spoke, I'll also add a static NHRP mapping on hub2 to hub1, just like the spokes.

hostname dc2-r1 ! interface tunnel1 ip nhrp map 10.172.0.1 100.0.0.2 ip nhrp map multicast 100.0.0.2 ip nhrp nhs 10.172.0.1 _____________________________________________ hostname Spoke1 ! interface tunnel1 ip nhrp map 10.172.0.5 100.0.0.26 ip nhrp map multicast 100.0.0.26 ip nhrp nhs 10.172.0.5 _____________________________________________ hostname Spoke2 ! interface tunnel1 ip nhrp map 10.172.0.5 100.0.0.26 ip nhrp map multicast 100.0.0.26 ip nhrp nhs 10.172.0.5 _____________________________________________ hostname Spoke3 ! interface tunnel1 ip nhrp map 10.172.0.5 100.0.0.26 ip nhrp map multicast 100.0.0.26 ip nhrp nhs 10.172.0.5

Why is it necessary to statically map hub1 on hub2? There doesn't HAVE to be this NHRP binding for the network to function. If I don't add a map on hub2, the OSPF neighbors will look like this: ![](/content/images/2016/07/hub2-ip-ospf-no-static.PNG) The routing table will populate and there will be connection to every network, even those behind hub1. The issue is that all traffic from hub2 to hub1 will go through the spokes. The hubs will likely be connecting with more bandwidth than any spoke, so it'd be very easy to choke the spoke routers, if traffic has to route through those. Add the configuration on hub2 and it'll become our BDR for the network.

By now I hopefully have a redundant setup. Time to test some traceroute from spoke1 after closing the tunnel on hub1.


The red line marks when I shut the tunnel interface on hub1. What can be interpreted here is that networks previously mapped will continue to route just fine. Even if the networks were to time out at some point, they'll be able to instantly re-map, as it'll probably happen after the network has converged. In regards to convergence, it's evident that reconvergence is very undesirable. GNS3 is not an exact accurate display of convergence time, but it gives an idea. It's possible to get a faster convergence by lowering timers, like OSPF hello/dead. However, it's important to keep in mind that this is supposed to carry across the internet with no promise of reliability and may lead to neighbor flapping.

What's left

Path control and looking at different area designs + multiple DMVPN clouds.

Path control would be increasing path cost for something like hub2, to make sure traffic is sent to hub1. It doesn't make any sense to do with the setup I have here, though. I don't have any IP address that exists both places. Could be setting up an HA service or HSRP.

Default routing and summarization are also on the backlog, mainly because they are not too interesting to me with OSPF.

Doing multiple clouds and different design, perhaps an implementation with point-to-multipoint links, is something I'll save for later. I'd rather move to EIGRP and BGP first and get some ground on those. It'll likely be in this post I'll update/edit further OSPF into.

I'm still learning about the text formatting, making things look better and properly organizing the posts, which consumes time as well. But it's getting there.