cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2903
Views
0
Helpful
4
Replies

Advertise default routes from EIGRP stub?

jedavis
Level 4
Level 4

I have a 3560 with IP base that is acting as a true EIGRP stub router today.  It advertises local routes to the upstream service provider router and receives a default route.

Now I want to connect a 3900 ISR as a voice gateway.  The 3560 does not seem to be advertising any routes to the 3900.  Ok the EIGRP stub doc says this:

Only specified routes are  propagated from the remote (stub) router. The router responds to queries  for summaries, connected routes, redistributed static routes, external  routes, and internal routes with the message "inaccessible." A router  that is configured as a stub will send a special peer information packet  to all neighboring routers to report its status as a stub router.

Any neighbor that receives a packet informing it of the stub status will  not query the stub router for any routes, and a router that has a stub  peer will not query that peer. The stub router will depend on the  distribution router to send the proper updates to all peers.

I guess I don't understand why the stub advertises local routes to the upstream ISP router but does not seem to advertise routes to the 3900.  Does the stub identify the ISP router as the distribution router somehow, thus differentiating it from the 3900?  If so, how is this done?

show ip eigrp neighbor detail on the 3900:

EIGRP-IPv4 Neighbors for AS(100)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.1.1.100                Gi0/0             11 18:03:59    4   200  0  35

   Time since Restart 17:52:00

   Version 4.0/3.0, Retrans: 0, Retries: 0

   Topology-ids from peer - 0

   Stub Peer Advertising (CONNECTED STATIC SUMMARY ) Routes

   Suppressing queries

-Jeff

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Jeff,

I guess I don't understand why the stub advertises local routes to the  upstream ISP router but does not seem to advertise routes to the 3900.

One of the basic rules about EIGRP Stub routers is: if a route is already learned by EIGRP, do not advertise it further. Now, if your 3560 receives a default route via EIGRP, its stub configuration explicitly prohibits it from propagating it to the 3900. This is done because a stub router should - by definition - never be considered as a transit router. This is done by not advertising EIGRP-learned routes to other routers.

If you nevertheless need your 3560 to advertise the default route to the 3900, you can do it by configuring a so-called leak-map that allows selected EIGRP-learned routes to be advertised to neighbors.

The configuration on the stub router 3560 would be:

ip prefix-list DefaultRoute permit 0.0.0.0/0

!

route-map EIGRPLeak permit 10

match ip address prefix-list DefaultRoute

!

router eigrp 100

eigrp stub connected static summary leak-map EIGRPLeak

This should allow your stub router to advertise EIGRP-learned default route to other peers despite it is configured as a stub router.

Best regards,

Peter

View solution in original post

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

Hello Jeff,

I guess I don't understand why the stub advertises local routes to the  upstream ISP router but does not seem to advertise routes to the 3900.

One of the basic rules about EIGRP Stub routers is: if a route is already learned by EIGRP, do not advertise it further. Now, if your 3560 receives a default route via EIGRP, its stub configuration explicitly prohibits it from propagating it to the 3900. This is done because a stub router should - by definition - never be considered as a transit router. This is done by not advertising EIGRP-learned routes to other routers.

If you nevertheless need your 3560 to advertise the default route to the 3900, you can do it by configuring a so-called leak-map that allows selected EIGRP-learned routes to be advertised to neighbors.

The configuration on the stub router 3560 would be:

ip prefix-list DefaultRoute permit 0.0.0.0/0

!

route-map EIGRPLeak permit 10

match ip address prefix-list DefaultRoute

!

router eigrp 100

eigrp stub connected static summary leak-map EIGRPLeak

This should allow your stub router to advertise EIGRP-learned default route to other peers despite it is configured as a stub router.

Best regards,

Peter

First of all let me say that I was incorrect about local routes not  being advertised by the stub router.  I was not interested in receiving  those on the 3900 so I had filtered them out with a distribute-list that  permitted only 0.0.0.0.  When I remove the distribute list the 3560  stub does advertise connected routes to the 3900, but it still doesn't  advertise the default route (which is what I need).

And thanks Peter.  I was not aware that a stub router  would not redistribute routes learned from eigrp.  That is a pretty  important concept that I have not seen spelled out anywhere else.  This  would explain why the loopback interface advertised by the  3900 does not seem to propagate to the upstream ISP router.  The leak map is also a concept that I haven't seen.  It is a  fairly recent addition, as it is an option that is not present in the  12.2(44)SE code on the 3560 that I am dealing with.  It IS present in  another switch that I looked at that is running 12.2(55)SE.  I will be  replacing the one connected to the 3900 within a week (replacement is on  a truck headed to the site as I type this). It also has IP Base image  but is running 12.2(58)SE.  I will give it a shot when it arrives.

In the mean time I will simply use ip default-network statements to define a default route.  Thanks for the education.

-Jeff

Hello Jeff,

I was not aware that a stub router  would not redistribute routes learned from eigrp.

Yes... That is one of two defining properties of an EIGRP Stub feature:

  1. A stub router does not advertise routes that were learned via EIGRP themselves. This prevents the stub router from ever appearing as a successor or feasible successor to its neighboring router.
  2. Neighbors of an EIGRP Stub router aware of its stub status never send queries to that router during convergence. This both limits the query depth and again prevents a network from ever converging through a stub router.

In the mean time I will simply use ip default-network statements to define a default route.

No! Never! Avoid using the ip default-network at all costs. This command is an ugly hack and will most probably fail to do what you want it to (details some another time). Use the ip route 0.0.0.0 0.0.0.0 command to define a default route.

Best regards,

Peter

Um... ok Peter, I guess you don't like ip default-network!   But this is what I have:

Drawing25.jpg

I want to be sure that the 3945 has a valid default route if it loses either uplink.

Using ip default-network, I can do this on the 3945:

ip default-network 172.30.1.0

ip default-network 172.30.0.0

And I get this:

Gateway of last resort is 172.30.1.0 to network 172.30.0.0

The  3900 is reachable from an external device. 

So just for grins, I removed the default-network statements and tried this:

ip route 0.0.0.0 0.0.0.0 172.30.45.40

I get this:

Gateway of last resort is 172.30.45.40 to network 172.30.45.40

And again it is reachable from external addresses.  Both of these scenarios confused me a bit because the gateway of last resort isn't even connected, so how does it know how to get there?  Looking at the relevant entries in the routing table explains it. (in my test scenario here G0/1 on the 3945 is not connected)

S*    0.0.0.0/0 [1/0] via 172.30.1.0

      172.30.0.0/29 is subnetted, 1 subnets

D        172.30.1.0

           [90/31232] via 10.2.0.2, 04:58:08, GigabitEthernet0/0

And again it is reachable from external addresses.  So I guess I could do it either way. I didn't realize I could do this with a static default route pointing at a non-connected subnet.  Or does this open me up to same unexplained problems that ip default-network creates?

As a pracitcal matter this doesn't mean much as I should be able to configure the leak-map prior to production, but I am curious.

-Jeff