Debugging an EIGRP Stub

After a certain amount of time, you start to forget some of the smaller details that you do not use on a regular basis.  Constantly teaching CCNA and CCNP, makes it very easy to recall nearly all of the details of the major routing protocols.  After not teaching for a good couple of years now, I still remember a good bit, but sometimes the smaller things escape me.  One of these types of things would be the finer details of stub routing.  Stub routing is intended to increase scalability, help smaller routers from being overwhelmed with routing updates, and keeps spokes from being used as an alternate route for hub routers.  I was having trouble figuring out why a certain route was not being advertised like I had expected it to, so I initiated a debug to take a look at the router’s “thought process”.  After finishing up and showing a couple of Marines what the debug looked like, it occurred to me this would make a nice post.

I put together a little lab to illustrate this.  Router 2 is an EIGRP stub and the POP router (DMVPN spoke) for your site, and Router 3 is the router at your Headquarters (DMVPN hub).  I put a loopback on R1 and used a static route to reach it (to represent another network that is unable to use EIGRP, like an ANW2 network).

After configuring R2 as an EIGRP stub (command is “eigrp stub connected” under the routing process), I turned on the debug for EIGRP (debug ip eigrp).  Here is what the output looked like:

This output takes you route by route through the router’s decision making process.  When I was troubleshooting this in the example for the post, my ANW2 network was not being advertised (represented by the 1.1.1.1/32 network in the output).  This is specifically what I was looking for:

Now that we know it was denied by the stub, we need to modify the stub behavior to get this to work.  Here are the different stub options:

The 1.1.1.1/32 network is a redistributed route, so we need to get to add those into our stub configs.  Remember that you need to keep your connected routes as well (don’t wanna take 1 step forward and 2 steps back).  Entering the following commands can get us where we need to be:

Our previous debug was still running, and sure enough, here is the update to our route:

The last thing we need to do is verify the route is reachable from the router it was sent to (R3):

Now that you know the basics of how EIGRP stubs work, and how to make changes necessary for your situation, you should have a bit more success with your stub usage.