EIGRP router wont UPDATE its neighbor with a new network

Answered Question
Apr 19th, 2012

I am working at a client site today on a routing issue.  I am currently working on an issue where a 3750 switch running EIGRP will not update its neighbor router when a network statement is added to the eigrp instance.

The neighbor is a 3825 router.

Both the switch and the router have a common network which is 192.168.36.0/24.

Both the switch and the router are in a neighbor adjacency.

Both boxes have "no auto-summ" in the routing configuration instance.

I can run debugs on both routers (debug eigrp packets) and then I can watch queries and updates when I issue "auto-summ" or "no auto-summ".  Also I see a "graceful restart" for the peers when this is done.

I had an expectation that when I added the network (this is just an arbitrary network for testing, which is 172.16.69.0/24).  I wanted to watch this network being sent in an update to the neighbor router.

When I add the above mentioned network, there are no updates packets sent from the 3750 to the 3845.  I have not had success to this point trying to resolve.  I have followed the Cisco document "Troubleshooting EIGRP Flow Chart", but have exhausted all it has to offer and now it is at the point where it is telling me to contact TAC.

I wanted to post this first.  I am sure this is something simple I am missing.  I appreciate any and all help.

Thank You.

I have this problem too.
0 votes
Correct Answer by dancicioiu about 1 year 11 months ago

Hi Kevin,

First of all I have to explain why I do think that you need to filter :

when you create a summary route on the eigrp , even though you are creating it on the interface, the eigrp process will have this route in the topology and it will advertise the summary to any eigrp neighour.

So if you want to make two summaries ( 1 client routes and 1 BP routes ) we have to prevent this routes going to BP ( the BP summary )  and  to client ( the Clinet summary ).

Furthermore you will advertise a summary route of the client to BP network, I do not know if the BP network filters the advertisements but there are some chances that this summary will reach your 3750 HQ switch and then goes to the client.

Where you have indicated that I should "filter OUT - on the MPLS interface the CLIENT summary...  Do I use a distribute list with a deny statement to accomplish this?

Yes, on 3750  DR, yes and set the distribute list on the client interface ( or SVI ). For example

distribute-list CLIENT-OUT out fa1/0/1

or

distribute-list CLIENT-OUT out Vlan 5

ip access-l stan CLIENT-OUT

deny

permit any

The client's summary should be created on the interface toward the BP.

Where you have indicated that I should "filter OUT - on the BP interface the BP summary....   We do not have access to the BP router, so I would only be able to accomplish this by working with the BP.  I know this isnt a quesiton per say, but did want to document that with you.

No, it's the same as for the client summary.

interface

ip summary-address eigrp #

ip access-l stan BP-OUT

deny

permit any

router eigrp #

distribute-list BP-OUT out

Now comes to my mind that you have to filter this BP-summary also on HQ 3750 , coming from MPLS. (!!!)

Where you have indicated that I should "filter IN - on the BP interface the CLIENT summary...  Do I use a distribute list with a permit statement to accomplish this?

No. On HQ 3750 you will have 2 filters related to the summary made on DR:

access-list stan BP-IN

deny

permit any

access-list stan CLIENT-IN

deny

permit any

router eigrp #

distribute-list CLIENT-IN in

distribute-list BP-IN in

Because you do not want the BP summary that was created on DR and you do not want the client summary also made by the DR.

The HQ 3750 is currently not configured as a stub. 

That's good ! Then on HQ 3750 will only filter the summaries made by the DR 3750

Regards

Dan

Correct Answer by dancicioiu about 1 year 12 months ago

Hi Robert,

Routing Protocol is "eigrp 13"

Stub, connected

Having stub will not stop you advertising conncted subnets.

Kevin tried to advertise something that did not exist in the routing table.

Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.2 (9 ratings)
dancicioiu Thu, 04/19/2012 - 13:11

Hi Kevin ,

Please paste from your 3750 :

show ip route 172.16.69.0

show ip eigrp topology 172.16.69.0 255.255.255.0

show ip eigrp nei

show ip protocols

Dan

k-melton Thu, 04/19/2012 - 13:31

Dan

Thanks for your quick response.

If i perform a "sho ip route 172.16.69.0" on the WAN switch, it does not show the subnet.  This is not a real route.  I was only using it for testing. Is this an issue?

If it is, then what I need to publish now is that there are several Real network statements on the WAN switch which do not seem to make it to the 3845 router.  On the 3845 router, I should see Feasible successors under the Successor on the EIGRP topology table, but do not. 

LOWANSWT#sho ip route 172.16.69.0

% Subnet not in table

LOWANSWT#show ip eigrp topology 172.16.69.0 255.255.255.0

EIGRP-IPv4 Topology Entry for AS(13)/ID(192.168.38.5)

%Entry 172.16.69.0/24 not in topology table

LOWANSWT#sho ip eigrp nei

EIGRP-IPv4 Neighbors for AS(13)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   192.168.36.1            Vl36              11 00:48:26    1   300  0  6751

2   172.28.6.130            Gi1/0/4           12 2d00h       1   200  0  981

0   192.168.36.3            Vl36              14 2d00h       6   300  0  625

Routing Protocol is "eigrp 13"

  Outgoing update filter list for all interfaces is not set

    GigabitEthernet1/0/1 filtered by PJM_ODEC, default is PJM_ODEC

  Incoming update filter list for all interfaces is not set

  Default networks flagged in outgoing updates

  Default networks accepted from incoming updates

  Redistributing: eigrp 13

  EIGRP-IPv4 Protocol for AS(13)

    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0

    NSF-aware route hold timer is 240

    Router-ID: 192.168.38.5

    Stub, connected

    Topology : 0 (base)

      Active Timer: 3 min

      Distance: internal 90 external 170

      Maximum path: 4

      Maximum hopcount 100

      Maximum metric variance 1

Automatic Summarization: disabled

  Maximum path: 4

  Routing for Networks:

    172.16.69.0/24

    172.28.6.136/32

    172.28.6.128/28

    172.28.0.0

    192.168.36.0

    192.168.38.0

    206.223.104.0/25

    206.223.104.128/25

  Routing Information Sources:

    Gateway         Distance      Last Update

    (this router)         90      02:20:31

    172.28.6.130          90      00:51:12

    192.168.36.1          90      00:51:11

    192.168.36.3          90      00:51:14

Distance: internal 90 external 170

LOWANSWT#sho ip prot
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 13"
  Outgoing update filter list for all interfaces is not set
    GigabitEthernet1/0/1 filtered by PJM_ODEC, default is PJM_ODEC
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  Redistributing: eigrp 13
  EIGRP-IPv4 Protocol for AS(13)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 192.168.38.5
    Stub, connected
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1

dancicioiu Thu, 04/19/2012 - 13:39

Yes this is the issue , it must be 'real' and present in the Rt in order to advertise it.

Regarding the real network statments that you have to publish could you tell me which ones are ? Are they on the routing table ?

Dan

k-melton Thu, 04/19/2012 - 13:53

Sure thing.  Here is the EIGRP off of the WAN switch...

router eigrp 13

distribute-list PJM_ODEC out GigabitEthernet1/0/1

network 172.16.69.0 0.0.0.255

network 172.28.0.0

network 172.28.6.128 0.0.0.15

network 172.28.6.136 0.0.0.0

network 192.168.36.0

network 192.168.38.0

network 206.223.104.0 0.0.0.127

network 206.223.104.128 0.0.0.127

neighbor 172.28.6.130 GigabitEthernet1/0/4

passive-interface Vlan101

eigrp stub connected

the networks i want advertised from the WAN switch to the MPLS router are the 206 networks that you see.  The MPLS router (sorry the 3845) already knows of the routes from another Primary BGP path.  We need for this to be the backup (Feasible Successor) path.

They are in the routing table:

LOWANSWT#sho ip route 206.223.104.0
Routing entry for 206.223.104.0/24, 2 known subnets
  Variably subnetted with 2 masks

D EX    206.223.104.0/26
           [170/10258432] via 172.28.6.130, 2d01h, GigabitEthernet1/0/4
D EX    206.223.104.128/25
           [170/10258432] via 172.28.6.130, 2d01h, GigabitEthernet1/0/4

but they are in the table because the business Partner is advertising them to us (6.130 address is our BP router).  Once again, can I not advertise routes that are not connected to the router?  Is this me needing to redistribute the routes from the neighbor rather than including them in network statements?

Thanks again Dan

cawfehman Thu, 04/19/2012 - 13:51

What license level do you have for the 3750?  IPbase only permits STUB routing.  You'll need the IP services license for full fledged EIGRP.

Correct Answer
dancicioiu Thu, 04/19/2012 - 13:56

Hi Robert,

Routing Protocol is "eigrp 13"

Stub, connected

Having stub will not stop you advertising conncted subnets.

Kevin tried to advertise something that did not exist in the routing table.

Dan

k-melton Tue, 04/24/2012 - 09:11

Dan

I wanted to circle back with you on this as I did not get any response from the last individual whom had kinda jumped in the middle.

Am I correct then to assume that a route must be in the routing table of a router to be advertised?

Thanks

Kevin

dancicioiu Tue, 04/24/2012 - 11:58

Hi Kevin ,

Yes in order to be advertised, first of all you have to have it on the routing table.

In your particular setup , the EIGRP is configured as STUB , this means the it cannot be a transit router - although we can improvise and make it work, I think, but this depends on your setup.

As you see "eigrp stub connected" : this means that the EIGRP is a stub and cannot advertise only connected routes.

Can you discribe your issue and also your setup ? Where does this equipment stands in your topology.

Regards

Dan

k-melton Wed, 04/25/2012 - 06:11

Can you discribe your issue and also your setup ? Where does this equipment stands in your topology.

Dan here is the situation. 

The client I am working at has a HQ building and a Disaster Recovery building.  The client connects to a Business Partner at each location thru a router and a WAN connection.  Their onsite router at each of the two respective locations then connects in to us on one of our switches.  The switches are 3750 boxes.

The WAN connection at the HQ location is our Primary Path.

The Business Partner advertises their networks to us in an EIGRP process on their router.  I see the advertised routes on our switches in each location from the BP.

What we need is each switch to then re-advertise the learned routes to its other neighbors, the main one of which is our MPLS routers which connect the HQ site to the DR site.  For whatever reason, the routes from the switches need to be advertised to the MPLS routers, which would in turn tell each other of the alternate route to the BP, subsequently when I look at the EIGRP topology table on each of our MPLS routers or switches, I should see 1 successor route and then the feasable successor route which would work for us assuming we lost the primary circuit.

What is not happening is our switches which connect to the BP get the routes from the BP, but do not advertise the routes to their MPLS neighbor routers, which we need for them to do.

Here is the configuration with respect to EIGRP on the HQ switch:

router eigrp 13

network 172.27.6.128 0.0.0.15

network 192.168.15.0

network 206.223.104.0

network 206.223.105.0

neighbor 172.27.6.130 GigabitEthernet3/0/15

distribute-list EIGRP_OUT out GigabitEthernet3/0/15

distribute-list route-map eigrp-rm out

distribute-list eigrp in

no auto-summary

Here is the configuration with respect to EIGRP on the HQ switch:

router eigrp 13

distribute-list PJM_ODEC out GigabitEthernet1/0/1

network 172.28.0.0

network 172.28.6.128 0.0.0.15

network 172.28.6.136 0.0.0.0

network 192.168.36.0

network 192.168.38.0

network 206.223.104.0 0.0.0.127

network 206.223.104.128 0.0.0.127

network 206.223.105.0

network 206.223.105.0 0.0.0.127

neighbor 172.28.6.130 GigabitEthernet1/0/4

passive-interface Vlan101

eigrp stub connected

Here is a list of the networks being advertised to us from the BP at the HQ switch:

206.223.104.0/24 is variably subnetted, 2 subnets, 2 masks

D EX    206.223.104.0/26

           [170/53760] via 172.27.6.130, 1w4d, GigabitEthernet3/0/15

D EX    206.223.104.128/25

           [170/53760] via 172.27.6.130, 1w4d, GigabitEthernet3/0/15

the 172.27.6.130 address is the BP router.

Here is a list of the networks being advertised to us from the BP at the DR locaiton:

206.223.104.0/24 is variably subnetted, 2 subnets, 2 masks

D EX    206.223.104.0/26

           [170/10258432] via 172.28.6.130, 1w0d, GigabitEthernet1/0/4

D EX    206.223.104.128/25

           [170/10258432] via 172.28.6.130, 1w0d, GigabitEthernet1/0/4

That being said, the MPLS routers which are neighbors to each of these do not have these networks in their routing tables.

Thanks again for any help on this that you can provide.

dancicioiu Wed, 04/25/2012 - 14:50

Kevin ,

Personaly I will go for the upgrade, meaning full EIGRP.

As a workaround you can use :

     1) eigrp leak-map , will permit you forward required prefixes even though you are stub

             ip prefix-list EIGRP-LEAK permit 206.223.104.0/26

             ip prefix-list EIGRP-LEAK permit 206.223.104.128/25

               !

               route-map EIGRP-LEAK

                  match ip address prefix EIGRP-LEAK

               !

               router eigrp 13

                eigrp stub connected leak-map EIGRP-LEAK

     2) "eigrp stub connected summary" , and create on the interface toward the MPLS routers ( if i understood well )

                      for example Gi1/0/1 is the interface toward the MPLS routes

                            int gi1/0/1

                              ip summary-address eigrp 13 206.223.104.0 255.255.255.0

                more specific prefixes will be learned from the main site , the summary will be learned from the DRC

                The minus here is that you have to do manual summarization carfully, for every prefix that is in transit.

By the way you do not have to add "network" commands for those prefixes that are in "transit".

The network command is only for those prefixes that are advertise to the EIGRP domain by the local router.

Regards

Dan

k-melton Thu, 04/26/2012 - 06:29

I am a little wary of using the
"ip summary-address eigrp " statement on the interface.  you had indicated that

"you have to do manual summarization carfully, for every prefix that is in transit." 

I wanted to talk more about that  specific statement.  Are you saying that I would have to summarize more routes than just the 206.223.104.0/26 and the 206.223.104.128/25 networks on that interface.  if that is the case, there are lots of networks that traverse that interface including all the production networks at the DR site. 

I am not sure if I have musunderstood the statement or not.  I dont mind putting the statement on the interface if I only have to do it for the networks in question.

Thanks Dan

dancicioiu Thu, 04/26/2012 - 12:11

Hi Kevin ,

I made a quick image with my understanding of your topology. Please correct me .

Dan

k-melton Thu, 04/26/2012 - 13:30

Here is a diagram for you Dan.  Hope this will help.  Thanks for all of your hard work on this.

Kevin

dancicioiu Fri, 04/27/2012 - 02:55

Hi Kevin ,

If I understood well you have the same issue on both switches (both of them have IP Base) ? Or just the one on the DRC.

I suppose that the client is located in the MPLS cloud. Please correct me if I'm wrong.

Dan

k-melton Fri, 04/27/2012 - 07:31

Dan

The Business Partner is actually not part of our MPLS network.  That is pretty much why I had drawn it the way that I did.

You are correct in that both of our 3750 switches (HQ and DR sites) are both running IP Base. 

I am not sure if we are having the same issue on the HQ side yet, as I was trying to just focus on the piece for the DR site, get that working, then turn my attention to the HQ side.

I will be back at that client site on Monday.  I can verify if we are having the same issue on the HQ side then.

Kevin

dancicioiu Fri, 04/27/2012 - 07:43

Ok, then. I will try to explain what is the workaround that I see and we will talk about the HQ site on Monday.

Short story :

        - on 3750 DRC

                - set "eigrp stub connected summary"

                - interface toward the BP : summary of the CLIENT prefixes

                - interface toward the MPLS : summary of the BP prefixes

                - filter OUT - on the MPLS interface the CLIENT summary - not to advertise this summary back to MPLS

                               - on the BP interface the BP summary - not to advertise this summary back to BP

        - on3750 HQ

                 - filter IN - on the BP interface the CLIENT summary - not to receive the CLIENT prefixes from BP

Its important if the HQ 3750 is also stub.

Regards

Dan

k-melton Thu, 05/03/2012 - 07:17

Dan

I have a couple of quesitons about your last recommendations. 

Where you have indicated that I should "filter OUT - on the MPLS interface the CLIENT summary...  Do I use a distribute list with a deny statement to accomplish this?

Where you have indicated that I should "filter OUT - on the BP interface the BP summary....   We do not have access to the BP router, so I would only be able to accomplish this by working with the BP.  I know this isnt a quesiton per say, but did want to document that with you.

Where you have indicated that I should "filter IN - on the BP interface the CLIENT summary...  Do I use a distribute list with a permit statement to accomplish this?

The HQ 3750 is currently not configured as a stub. 

Thanks Dan!

Correct Answer
dancicioiu Thu, 05/03/2012 - 09:06

Hi Kevin,

First of all I have to explain why I do think that you need to filter :

when you create a summary route on the eigrp , even though you are creating it on the interface, the eigrp process will have this route in the topology and it will advertise the summary to any eigrp neighour.

So if you want to make two summaries ( 1 client routes and 1 BP routes ) we have to prevent this routes going to BP ( the BP summary )  and  to client ( the Clinet summary ).

Furthermore you will advertise a summary route of the client to BP network, I do not know if the BP network filters the advertisements but there are some chances that this summary will reach your 3750 HQ switch and then goes to the client.

Where you have indicated that I should "filter OUT - on the MPLS interface the CLIENT summary...  Do I use a distribute list with a deny statement to accomplish this?

Yes, on 3750  DR, yes and set the distribute list on the client interface ( or SVI ). For example

distribute-list CLIENT-OUT out fa1/0/1

or

distribute-list CLIENT-OUT out Vlan 5

ip access-l stan CLIENT-OUT

deny

permit any

The client's summary should be created on the interface toward the BP.

Where you have indicated that I should "filter OUT - on the BP interface the BP summary....   We do not have access to the BP router, so I would only be able to accomplish this by working with the BP.  I know this isnt a quesiton per say, but did want to document that with you.

No, it's the same as for the client summary.

interface

ip summary-address eigrp #

ip access-l stan BP-OUT

deny

permit any

router eigrp #

distribute-list BP-OUT out

Now comes to my mind that you have to filter this BP-summary also on HQ 3750 , coming from MPLS. (!!!)

Where you have indicated that I should "filter IN - on the BP interface the CLIENT summary...  Do I use a distribute list with a permit statement to accomplish this?

No. On HQ 3750 you will have 2 filters related to the summary made on DR:

access-list stan BP-IN

deny

permit any

access-list stan CLIENT-IN

deny

permit any

router eigrp #

distribute-list CLIENT-IN in

distribute-list BP-IN in

Because you do not want the BP summary that was created on DR and you do not want the client summary also made by the DR.

The HQ 3750 is currently not configured as a stub. 

That's good ! Then on HQ 3750 will only filter the summaries made by the DR 3750

Regards

Dan

k-melton Tue, 05/08/2012 - 10:01

Dan

I found out from the client today that they are making the decision to buy routers instead of using the 3750's. 

I appreciate all of your efforts on this post!  I have learned alot from working with you.

I look forward to hearing from you again soon.

Kevin

Actions

Login or Register to take actions

This Discussion

Posted April 19, 2012 at 12:57 PM
Stats:
Replies:19 Avg. Rating:4.22222
Views:909 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 14,997
2 8,150
3 7,720
4 7,083
5 6,723
Rank Username Points
175
80
60
59
55