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.
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.
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.
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.
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.