EIGRP OTP Part 2
The snowmageddon in Virginia gave me some unexpected lab time, so I hopped back into VIRL and decided to kick the tires on some EIGRP OTP configuration. My first OTP post is here. As I mentioned in the first post, the main reason I wanted to kick the tires on OTP was to have an alternative to DMVPN to be used over SATCOM links. I’m most interested in keeping things simple. After giving the configs a run, this is pretty simple and could very easily be templated and taught.
Here is the topology I used as a proof of concept for what I was thinking:
I used a multipoint connection to simulate the ability to “learn” from a hub and still utilize spoke to spoke connectivity. The OTP spoke routers are there to simulate the router that you will plug into your Linkway modem, and the OTP hub is there to simulate the router that plugs into your hub modem (most likely wherever you put your MRT, Master Reference Terminal). I used three networks, the 192.168.1.0/24 network for Linkway traffic, the 172.16.1.0/24 and 172.16.2.0/24 for transport network connections, and 172.16.255.X/32 for loopbacks. I also used the 10.X.X.X networks to simulate backside networks (user subnets) that need to be routed. The 192.168.X.X and 172.16.X.X networks were routed using RIPv2 (Obviously not optimal, but necessary when interfacing with the Linkways), and EIGRP OTP was used to route the 10.X.X.X network.
Let’s take a look at the configs for this! Here are the routing configs for the OTP hub router:
The two networks advertised in RIP are the Linkway network (192.168) and the Loopback I will use for the EIGRP adjacency (172.16)**more on this later**. Under the EIGRP config, if you learned routing a while ago, you will notice this config uses EIGRP named mode, not EIGRP classic mode (Essentially, “router eigrp <name>” vs “router eigrp <asn>”). On the hub only, you need to go into the address family interface configuration for the interface you will use for adjacency (for me Loopback 0) and turn off split horizon and next hop self. Split horizon is a loop prevention mechanism that prevents a router from advertising routes learned from an interface out that same interface. Split horizon makes sense in point to point configurations, but in this case, if you did not turn it off, spoke 1 routes would never make their way to spoke 2 and vice versa because everything is learned from Loopback 0. Anyone familiar with BGP will understand the next hop self command, but for those who are not, interior routing protocols (EIGRP, RIP, OSPF) will take network advertisements they receive and set themselves as the next hop IP address before sending it out again. Again, for point to point interfaces this is great, but this configuration would be catastrophic in a SATCOM environment because ALL spoke to spoke traffic would have to go through the hub without next hop self turned off. The other command that is specific to the hub router is the “remote-neighbors” command, this is what denotes that you are using OTP. The “unicast-listen” portion is the part that is specific to a route-reflector server. This is the part that gives OTP scalability. Regardless of the number of spokes, all you need to do to get this working is to tell EIGRP the interface to listen to OTP peers on. The two networks advertised are the peering loopback (172.16)** and the loopback that is simulating your backside networks (10.1).
Now that we know what the hub looks like, let’s take a look at the spokes:
The RIP config remains the same. You will notice the EIGRP portion is simplified as you do not disable split horizon or turn off next hop self on the spoke routers. Additionally, the neighbor command is slightly different. Breaking it down: “neighbor <ip add of hub loopback> <your (peering) loopback interface> remote <max number of hops> lisp-encap”. Obviously for this topology I did not need 10 hops, but there may be instances where you need more than a couple. Just like with the hub, the 10.X network is advertised to simulate your backside networks behind this spoke router, and the 172.16 network is advertised because it is the loopback used for peering.
The spoke 2 configs are nearly identical, so I don’t think there will be much utility in going through them. It should be pretty clear this is a pretty simple config compared to DMVPN, but before we call this a day, there are some interesting things that should be pointed out.
I called it out earlier with the **, but I kinda committed one of the seven deadly sins. I’m not going to try to gloss over it, this one puzzled me. This WOULD NOT WORK until I advertised the peering loopback in EIGRP. The somewhat scary thing is this loopback is also advertised in RIP (as it needs to be). The main reason for the fear here is recursive routing. The concern being the loopbacks are initially seen because of RIP (Administrative Distance of 120), but I expected that when EIGRP agencies came up, those loopbacks would be advertised in EIGRP (AD of 90) and the tunnels would start going through themselves to get to themselves (recursive routing, which would cause the adjacency to flap). The concern was never realized as the tunnels never flapped. Take a look at the topology table for the three routers. Even though the peering loopback was advertised on all three routers (in EIGRP), each topology table only maintains its own peering loopback:
You can seen from the topology table that the only 172.16 address is a connected loopback. The other interesting thing from the topology table is on Spoke 1. Look at the info on the 10.3.3.3/32 network. The next hop IP address, and the address of the neighbor it was learned from is different. It may not seem like much to look at, but it is saving you 300+ milliseconds EACH DIRECTION.
The first time I configured DMVPN this blew my mind, but each spoke, regardless of the number of spokes, will only have one EIGRP neighbor (the hub). The hub will obviously have as many neighbors as there are spokes. Here is what that looks like:
The last thing I wanted to point out, just to prove OTP is not cheating or that I did not pull some schenanigans is show you that the routers I used to simulate the Linkway modems do not have any of the 10.X networks. Here are their routing tables:
As always, I am interested in hearing your feedback on whether you would consider using OTP to replace DMVPN. If you have any questions, just leave a comment and I will do my best to get back to you.