EIGRP Stub Routing

Introduction To EIGRP Stub Routing


Today we are going to look at the EIGRP stub routing feature.  The best place to go to get a thorough understanding of this that I have found out there is the following whitepaper from Cisco: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/eigrpstb.html

OK, so what is EIGRP stub routing and why do we care? According to Cisco, this feature basically accomplishes three things — improves network stability, reduces resource utilization, and simplifies stub router configuration. We will examine each of these things.  To assist in this, let’s look at the following example network

Here we have a pretty common hub and spoke frame-relay setup.  R2 and R4 are located at a corporate headquarters.  R5 is dual homed back to corporate headquarters via two frame-relay links (nevermind that we are using point-to-point subinterfaces on the same physical link.  The important thing logically here is that we have two connections and that was one way to accomplish that).  The hub routers R2 and R4 send down only the default-route to R5.

Improving Network Stability


To understand how EIGRP stub routing will improve network stability, we need to understand some things about how EIGRP works normally.

As far as network stability, stub routing accomplishes two main things.  Recall that when an EIGRP router loses a route and does not have a feasible successor for that route, it will go active and query all of it’s neighbors. If the router doesn’t hear back in 3 minutes, the route will be “stuck in active” and could cause routing issues in the rest of the network.  Without stub routing turned on in our example, if R2 or R4 loses some route that sits up in the corporate network behind the hub routers, they may query R5 for those routes.  This consumes resources  on R5 and consumes precious bandwidth on the WAN links. It also opens the possibility of the route getting stuck in active if there are communication problems on the WAN.  Furthermore, in this situation it really makes no sense because there are no other routers sitting behind R5 — It is a stub router by definition. When we configure R5 as an EIGRP stub, R5 will notify R2 and R4 that it is a stub router. In doing so, we prevent R2 and R4 from ever sending queries to R5 for active routes, so we eliminate that problem. If R5 should ever receive a query, it will simply reply “inaccessible”.

The second thing in regards to network stability that EIGRP stub routing gives us is automatically preventing suboptimal transit routing.  Imagine for a second that the LAN link over VLAN 24 between R2 and R4 was a GigabitEthernet link in a high speed corporate LAN.  The main frame-relay link between R5 and R2 is a T1 line and the backup frame-relay link between R5 and R4 is 128k.  Now imagine that there is some sort of problem on VLAN 24 and R2 loses EIGRP adjacency with R4.  What would happen?  R4 would continue sending EIGRP routes for the corporate LAN down to R5.  R5 would in turn send them up to R2.  R2 could then route traffic destined for somewhere else on the corporate network over the T1 link to R5.  That could be a LOT of traffic for a T1 but then R5 is going to turn around and try to cram all of that down a 128k frame-relay link back up to R4!!!  What you have is inherent disaster.  In these cases you really don’t want to allow intra-HQ traffic to route through your site WAN links. R5 really only needs to advertise in it’s directly connected routes and nothing else. EIGRP stub routing also fixes this problem.  When you enable R5 as an EIGRP stub, R5 by default will ONLY advertise to it’s neighbors directly connected and summary routes by default.  The feature can be tweeked to also include redistributed routes from other protocols or redistributed static routes. What this means is that when R5 learns routes from say R4 it will NOT relay those routes back up to R2.  R5 will also not relay routes learned from R2 up to R4.  This prevents R5 becoming a “transit” router for HQ routes.

Reducing Resource Utlization


First of all, in a setup like this, R5 has no reason whatsoever to have any EIGRP routes other than the default route because no matter where packets need to go outside the local network, those packets need to go through R2 or R5.  Anything more than the default route is a waste of R5’s resources.  That particular piece of the puzzle doesn’t have to do with stub routing, but is generally something you will see in these topologies.  The resource reduction part of this feature we have already talked about.  Mainly, it means R5’s resources do not become consumed by EIGRP queries.  Since queries won’t be sent over the WAN, we also consume WAN bandwidth.  Also, R5 would send end up sending way less routes as well.  Imagine that we did not filter and sent every HQ route down to R5 and that R5 learned 1000 routes from R4.  Without stub routing, R5 would send those 1000 routes back up to R2.

Simplifying Configuration.


Simplifying configuration is a bit of as stretch in my opinion, but the argument is that because R5 automatically does not send anything except connected and summary routes, we no longer need to configure outbound distribute-lists to prevent R5 from becoming a transit router.

Configuration


EIGRP stub configuration is very straight forward.  It requires no changes on the upstream routers.  We simply configure the eigrp stub command on the remote stub router.  When this happens, the stub router will actually notify it’s neighbors that it is a stub router.  This let’s the neighbor routers know to not query the stub router for active routes. Let’s look at this on R5

router eigrp 100
 network 25.25.25.2 0.0.0.0
 network 45.45.45.2 0.0.0.0
 no auto-summary
 eigrp stub

We enabled EIGRP on both frame-relay links. We enabled stub routing, which we said by default advertised directly connected and summary routes. However, if I look at R2, I don’t see my 5.5.5.5 route

R2#sh ip route e
     4.0.0.0/32 is subnetted, 1 subnets
D       4.4.4.4 [90/156160] via 24.24.24.4, 01:03:16, FastEthernet0/0
     45.0.0.0/30 is subnetted, 1 subnets
D       45.45.45.0 [90/2172416] via 24.24.24.4, 00:01:45, FastEthernet0/0
D*   0.0.0.0/0 is a summary, 00:22:07, Null0

Although the stub feature does advertise connected routes by default, you still need network statements that cover those interfaces.

R5(config)#router eigrp 100
R5(config-router)#network 5.5.5.5 0.0.0.0

R2#sh ip route e
     4.0.0.0/32 is subnetted, 1 subnets
D       4.4.4.4 [90/156160] via 24.24.24.4, 01:04:23, FastEthernet0/0
     5.0.0.0/32 is subnetted, 1 subnets
D       5.5.5.5 [90/2297856] via 25.25.25.2, 00:00:17, Serial0/1/0.25
     45.0.0.0/30 is subnetted, 1 subnets
D       45.45.45.0 [90/2172416] via 24.24.24.4, 00:02:52, FastEthernet0/0
D*   0.0.0.0/0 is a summary, 00:23:14, Null0

Let’s add a static route now, and modify the stub configuration on R5.

R5(config)#ip route 100.100.100.0 255.255.255.0 45.45.45.1
R5(config)#router eigrp 100
R5(config-router)#eigrp stub connected static

Now look at R2 again.

R2#sh ip route e
     4.0.0.0/32 is subnetted, 1 subnets
D       4.4.4.4 [90/156160] via 24.24.24.4, 01:06:23, FastEthernet0/0
     5.0.0.0/32 is subnetted, 1 subnets
D       5.5.5.5 [90/2297856] via 25.25.25.2, 00:00:24, Serial0/1/0.25
     45.0.0.0/30 is subnetted, 1 subnets
D       45.45.45.0 [90/2172416] via 24.24.24.4, 00:00:24, FastEthernet0/0
D*   0.0.0.0/0 is a summary, 00:25:14, Null0

I don’t have the route to 100.100.100.0/24. Why? Even though I added the static keyword to the eigrp stub command, I still need to redistribute static to get the route to be advertised from R5

R5(config)#router eigrp 100
R5(config-router)#redistribute static metric 1 1 1 1 1

Now R2 should see our 100.100.100.0/24 route

R2#sh ip route e
     100.0.0.0/24 is subnetted, 1 subnets
D EX    100.100.100.0
           [170/2560512256] via 25.25.25.2, 00:00:52, Serial0/1/0.25
     4.0.0.0/32 is subnetted, 1 subnets
D       4.4.4.4 [90/156160] via 24.24.24.4, 01:08:22, FastEthernet0/0
     5.0.0.0/32 is subnetted, 1 subnets
D       5.5.5.5 [90/2297856] via 25.25.25.2, 00:02:23, Serial0/1/0.25
     45.0.0.0/30 is subnetted, 1 subnets
D       45.45.45.0 [90/2172416] via 24.24.24.4, 00:02:23, FastEthernet0/0
D*   0.0.0.0/0 is a summary, 00:27:13, Null0

Verification


We can verify a stub router configuration by look at the upstream neighbors.  If a neighbor is configured as a stub router, it will report that information in the output of show ip eigrp neighbor detail 

R2#show ip eigrp neighbor detail
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   25.25.25.2              Se0/1/0.25        13 00:04:59   42   252  0  105
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 3
   Stub Peer Advertising ( CONNECTED STATIC ) Routes
   Suppressing queries
0   24.24.24.4              Fa0/0             11 01:10:57    1   200  0  106
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 4

R4#sh ip eigrp neighbor detail
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   45.45.45.2              Se0/0.45          11 00:05:36  836  5000  0  106
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 3
   Stub Peer Advertising ( CONNECTED STATIC ) Routes
   Suppressing queries
0   24.24.24.2              Et0/0             14 01:11:34    1   200  0  109
   Version 12.4/1.2, Retrans: 2, Retries: 0, Prefixes: 4

That about does it for EIGRP stub routing.

Tags: , , , , , , ,

10 Comments

Leave a Reply