Like This Blog 4

Added by Mark Jacob June 9, 2014

If you are keeping up with Cisco’s announcements regarding EIGRP, you are aware that Cisco has released their proprietary routing protocol into the open. However, one of the pieces they are keeping close to the vest is the stub feature.  If your environment has need of this functionality, this blog may enlighten you as to its configuration and results.

My goal in this blog is to use packet captures with Wireshark to dig a little deeper into what happens on the network when this feature is deployed.  Here is the scenario:

In the above network, R3  is configured with the command (from config-router mode)

eigrp stub receive-only

I have Wireshark monitoring the link between R2 and R3 so that I can see the EIGRP packets as they cross the wire.  All three routers are running EIGRP, and R1 is advertising the network 192.168.1.0/24.  While I am monitoring the link, I will go to R1 and shutdown Loopback 0, thus killing that network.  Since R2 and R3 are downstream from this network topology change, I should see some action on the wire in response.  Let’s take a look.

I have highlighted that a Query message was sent. Keep in mind that if an EIGRP router has no feasible successor in its topology table, the next step is to query neighbors for a possible replacement route. However, with the stub feature enabled, perhaps we were expecting to see no query messages being sent. After all, this is what the stub feature is supposed to accomplish. This is where it helps to dig a little deeper.  You will note that the source IP address of the query is 172.20.1.2 and the destination IP address is 224.0.0.10 (EIGRP’s multicast address). So while there was a query, it was generated by R3 back in the direction of R2.  R2 behaved correctly by not sending a query to R3.

You might then wonder why you wouldn’t just configure R2’s f0/1 interface as a passive-interface. If you did that, R2 and R3 would not form an EIGRP neighbor relationship.  This is not what we are trying to do – we just want to leave R3 out of the loop when query messages arise.  In the tiny network shown above, you could conclude that there is not much benefit to using the stub feature. Admittedly this is the case, but here is where you make the mental leap to extrapolate the stub feature benefits into an enterprise-level network. Because querying is not a particularly fast process, leaving out participants where it is feasible to do so will speed up convergence in large networks by ignoring routers that couldn’t possibly have an alternate route.

There are other stub options that can be configured.  The list looks like this:

–        receive-only

–        connected

–        static

–        summary

–        redistribute

If you configure the receive-only option, you can’t include any of the other options on the above list.  If you just configure the router as a stub and don’t specify any option, the default behavior is to share connected and summary routes.  Some other caveats also arise when using these options.  For instance, if you configure the static option, you still must allow EIGRP to share the static routes by issuing the redistribute static command in the config-router context, or the router won’t share the routes.  The same goes for the connected option.  If a network statement does not include the connected routes you want to share, then you must issue the redistribute connected command.  One last aspect which may seem counterintuitive is that if you use the redistribute option, you are permitting the router to share redistributed routes, but you still must actually redistribute the routes for them to be shared.  If you choose the summary option, don’t forget to either manually create summary routes or enable auto-summary.

If you are a routing person, then you may already be familiar with stub areas in OSPF.  This is somewhat different from that.  In OSPF, it is an area that is a stub.  In EIGRP, the router itself is a stub router.  Once again, if you require this feature, be prepared to talk to Cisco as they own it and they are not sharing it!   Until next time…
Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ