EIGRP Issue Not Accepting Routes from Neighbor

Answered Question
Jun 30th, 2010

I have an issue I am trying to understand with EIGRP not accepting or not using routes advertised from an EIGRP neighbor.  Router A is directly connected to Router B, and both have established eigrp neighbor relationship with one another.  When displaying IP PROTOCOL, Router A does not list Router B as a Routing Information Source, but Router B does show Router A as a Routing Information Resource.  Router B has 5 directly connected networks it is advertising to Router A, but Router A will not put the networks in it's routing table, nor are they in the topology table.  What would cause this?  Below are snipets from the two routers:

Router A

interface Multilink203386
ip address 10.250.241.66 255.255.255.252
ip route-cache flow
delay 20
ppp multilink
ppp multilink group 203386
max-reserved-bandwidth 100
service-policy output UDN-EDGE

!

router eigrp 2013
network 10.0.0.0
auto-summary

!

IP-EIGRP neighbors for process 2013
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
7   10.250.241.65           Mu203386          12 14:14:54    1   200  0  1532
6   10.250.170.154          Mu205680          12 6w3d        3   200  0  83199
4   10.250.170.106          Se1/3:0           13 6w3d        6   200  0  584572
5   10.250.170.114          Mu204840          14 10w1d       1   200  0  1505421
1   10.250.100.93           Se6/1             11 14w3d       1   200  0  4207627
8   10.250.170.217          Hs5/0             11 14w4d       5   200  0  346884
0   10.250.170.202          Se6/0             12 15w2d       1   200  0  2246571
2   10.250.110.53           Se3/0             11 17w5d       1   200  0  5440745
3   10.250.170.133          Se3/1             10 40w2d       1   200  0  2682260

!

sh ip protocols

Routing Information Sources:
    Gateway         Distance      Last Update
    10.250.170.114        90      00:10:58
    10.250.170.106        90      00:10:58
    10.250.170.217        90      00:10:58
    10.250.170.202        90      00:10:58
    10.250.110.53         90      00:10:58
    10.250.170.154        90      00:10:58
    10.250.100.93         90      00:10:58
    10.250.170.150        90      10w4d
    10.250.170.133        90      00:10:58

Router B

interface Multilink203386
ip address 10.250.241.65 255.255.255.252
delay 20
ppp multilink
ppp multilink group 203386
max-reserved-bandwidth 100
service-policy output UDN-EDGE

!

router eigrp 2013
network 10.0.0.0
auto-summary

!

IP-EIGRP neighbors for process 2013
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
5   10.168.1.10             Gi1/0.300         13 14:20:02    1   200  0  61786
4   10.250.130.69           Se0/0/0:0         12 14:20:02    4   200  0  531447
3   10.250.241.66           Mu203386          14 14:20:02    1   200  0  3056950
2   10.168.1.11             Gi1/0.300         13 14:20:02    1   200  0  61189
1   10.168.1.9              Gi1/0.300         10 14:20:02    2   200  0  61342
0   10.168.1.3              Gi1/0.300         13 14:20:02    1   200  0  53499

!

sh ip protocols

Routing Information Sources:
    Gateway         Distance      Last Update
    10.250.130.69         90      00:01:49
    10.250.241.66         90      00:01:49
    10.168.1.3            90      00:01:50
    10.168.1.11           90      00:01:50
    10.168.1.10           90      00:01:50
    10.168.1.9            90      00:01:50

Correct Answer by Richard Burts about 6 years 7 months ago

I am glad that you have got the problem resolved. Thanks for posting back to the forum about it. Perhaps you could mark the question as solved. This would benefit other people who might read the thread to find out about the problem and about its solution.

Your solution of removing and rebuilding the multilink configuration is a stronger action but similar to my suggestion about interface shutdown/no shutdown. As I commented in a previous post I have seen situations where a routing protocol got confused or out of sync about a neighbor (sometimes it seems related to a configuration change made and then removed where the protocol seems to be remembering the change even though it is no longer in the running config, and sometimes we never had a clue what caused it) and terminating and rebuilding the neighbor relationship would solve the issue.

So congratulations on getting your problem resolved.

HTH

Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
John Blakley Wed, 06/30/2010 - 09:01

I'm going to say split-horizon. Try turning it off on the router that isn't seeing the routes:

no ip split-horizon eigrp 2013

The problem comes in when eigrp won't advertise routes on an interface that it learned it on. Be careful with disabling it though because it can wreak havoc on your network and cause loops. This is built-in to eigrp to prevent routing loops.

HTH,

John

Richard Burts Wed, 06/30/2010 - 09:53

John's suggestion of split horizon is interesting. I recently ran into a situation that may be similar to this which turned out to be duplicate router IDs on the two routers.

It would be helpful if the original poster would post some additional information. I would like to see:

- show ip interface brief from both routers.

- on router B a show ip route (or just part of it if the route table is large) especially including the routes on router B that are not advertised to router A.

- on router A a show ip route and/or show ip topology for some of the routes on router B that are not advertised to router A.

HTH

Rick

bssmith10 Wed, 06/30/2010 - 10:27

Below is some of the additional information you wanted to see.  Sorry, miscounted the number of directly attached networks to Router B.  You will see that Router A is receiving the networks directly connected to Router B from another direction, which I believe is causing asynchronous routing as Router B is accepting everything from Router A, but no matter how much I change the metrics from this other direction, Router A will not accept the networks from Router B.  I did look into the possibility of duplicate router ID's but found no evidence.  The routing tables are somewhat large so I just included the networks that I am having the issue with.

Router A

GigabitEthernet0/1         10.245.42.1     YES NVRAM  up                    up     
GigabitEthernet0/2         10.245.43.1     YES NVRAM  up                    up     
Serial1/2:0                unassigned      YES manual up                    up     
Serial1/3:0                10.250.170.105  YES NVRAM  up                    up     
Serial1/4:0                unassigned      YES NVRAM  up                    up     
Serial1/5:0                unassigned      YES NVRAM  up                    up     
Serial1/6:0                unassigned      YES manual up                    up     
Serial2/0:0                unassigned      YES NVRAM  up                    up     
Serial2/1:0                unassigned      YES NVRAM  up                    up     
Serial2/2:0                unassigned      YES NVRAM  up                    up     
Serial2/3:0                unassigned      YES NVRAM  up                    up     
Serial3/0                  10.250.110.54   YES NVRAM  up                    up     
Serial3/1                  10.250.170.134  YES NVRAM  up                    up     
Hssi5/0                    10.250.170.218  YES NVRAM  up                    up     
Serial6/0                  10.250.170.201  YES NVRAM  up                    up     
Serial6/1                  10.250.100.94   YES NVRAM  up                    up     
Multilink203386            10.250.241.66   YES manual up                    up     
Multilink204840            10.250.170.113  YES NVRAM  up                    up     
Multilink205680            10.250.170.153  YES NVRAM  up                    up     
Loopback256                10.249.80.117   YES NVRAM  up                    up 
!
sh ip ro | include 10.168.
D       10.168.2.244/30 [90/2555648] via 10.250.110.53, 01:55:55, Serial3/0
D       10.168.2.250/32 [90/2555648] via 10.250.110.53, 01:55:55, Serial3/0
D       10.168.2.253/32 [90/2555648] via 10.250.110.53, 01:55:55, Serial3/0
D       10.168.2.254/32 [90/2555648] via 10.250.110.53, 01:55:55, Serial3/0
D       10.168.1.0/24 [90/2427648] via 10.250.110.53, 01:55:55, Serial3/0
sh ip ro | include 10.245.103.0
D       10.245.103.0/24 [90/2427648] via 10.250.110.53, 01:57:17, Serial3/0
sh ip ro | include 10.190.5.0 
D       10.190.5.0/28 [90/2427648] via 10.250.110.53, 01:58:52, Serial3/0
sh ip ro | include 10.196.8.0
D       10.196.8.0/28 [90/2427648] via 10.250.110.53, 02:15:16, Serial3/0

Router B

Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0/0:0              10.250.130.70   YES NVRAM  up                    up     
Serial0/0/1:0              unassigned      YES manual up                    up     
Serial0/1/0:0              unassigned      YES manual up                    up     
GigabitEthernet1/0         unassigned      YES NVRAM  up                    up     
GigabitEthernet1/0.50      10.245.103.2    YES manual up                    up     
GigabitEthernet1/0.66      10.196.8.1      YES NVRAM  up                    up     
GigabitEthernet1/0.298     10.190.5.2      YES manual up                    up     
GigabitEthernet1/0.300     10.168.1.2      YES NVRAM  up                    up     
Multilink203386            10.250.241.65   YES manual up                    up     
Loopback256                10.249.30.89    YES NVRAM  up                    up     
!
sh ip ro
D       10.168.2.244/30
           [90/130816] via 10.168.1.3, 15:55:14, GigabitEthernet1/0.300
D       10.168.2.250/32
           [90/130816] via 10.168.1.9, 15:55:14, GigabitEthernet1/0.300
D       10.168.2.253/32
           [90/130816] via 10.168.1.10, 15:55:14, GigabitEthernet1/0.300
D       10.168.2.254/32
           [90/130816] via 10.168.1.11, 15:55:14, GigabitEthernet1/0.300
sh ip ro connected
     10.0.0.0/8 is variably subnetted, 1955 subnets, 14 masks
C       10.250.130.68/30 is directly connected, Serial0/0/0:0
C       10.250.241.64/30 is directly connected, Multilink203386
C       10.250.241.66/32 is directly connected, Multilink203386
C       10.245.103.0/24 is directly connected, GigabitEthernet1/0.50
C       10.168.1.0/24 is directly connected, GigabitEthernet1/0.300
C       10.190.5.0/28 is directly connected, GigabitEthernet1/0.298
C       10.249.30.88/30 is directly connected, Loopback256
C       10.196.8.0/28 is directly connected, GigabitEthernet1/0.66
D       10.250.240.0/30
           [90/846080] via 10.250.241.66, 15:56:24, Multilink203386
D       10.250.210.34/32
           [90/854016] via 10.250.241.66, 15:56:23, Multilink203386
D       10.250.200.56/30
           [90/4242688] via 10.250.241.66, 15:56:21, Multilink203386
D       10.250.160.80/30
           [90/2233600] via 10.250.241.66, 15:56:23, Multilink203386
D       10.250.140.124/30
           [90/3218944] via 10.250.241.66, 11:59:12, Multilink203386
D       10.250.120.136/30
           [90/848896] via 10.250.241.66, 15:56:22, Multilink203386
D       10.246.252.0/24
           [90/2196736] via 10.250.241.66, 15:56:22, Multilink203386
D EX    10.10.0.0/24
           [170/2570752] via 10.250.241.66, 15:56:24, Multilink203386
D EX    10.251.240.0/24
           [170/3471872] via 10.250.241.66, 15:56:21, Multilink203386
D EX    10.251.240.0/23
           [170/1295872] via 10.250.241.66, 15:56:22, Multilink203386
D       10.250.241.0/28
           [90/844032] via 10.250.241.66, 15:56:23, Multilink203386
D EX    10.249.90.168/30
           [170/844032] via 10.250.241.66, 15:56:22, Multilink203386
D       10.249.70.180/30
           [90/972288] via 10.250.241.66, 15:56:22, Multilink203386
D       10.246.253.0/24
           [90/2206208] via 10.250.241.66, 15:56:23, Multilink203386

Richard Burts Wed, 06/30/2010 - 10:44

Thank you. This additional information is helpful.

What I believe it shows is not so much that router A will not accept advertisements from router B but that router A is preferring routes for the prefixes from some other router.

Perhaps it will help us figure this out if you would post the output on router A of show ip eigrp topology 10.245.103.0 255.255.255.0

HTH

Rick

bssmith10 Wed, 06/30/2010 - 10:57

Agreed, which is why I attempted to make the routes from the other router even less desirable by changing metrics (primarily delay by as much as 50000milliseconds) so that the networks from Router B would be preferred.  You can already see that the networks such as 10.245.103.0 have a minimum bandwidth and total delay much worse than that over the link that directly connects Routers A and B.  Attached is the topology entry you asked for:

Router A

sh ip eigrp top 10.245.103.0 255.255.255.0
IP-EIGRP (AS 2013): Topology entry for 10.245.103.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2427648
  Routing Descriptor Blocks:
  10.250.100.93 (Serial6/1), from 10.250.100.93, Send flag is 0x0
      Composite metric is (2427648/2422528), Route is Internal
      Vector metric:
        Minimum bandwidth is 1344 Kbit
        Total delay is 20430 microseconds
        Reliability is 255/255
        Load is 8/255
        Minimum MTU is 1500
        Hop count is 5
  10.250.110.53 (Serial3/0), from 10.250.110.53, Send flag is 0x0
      Composite metric is (2427648/2422528), Route is Internal
      Vector metric:
        Minimum bandwidth is 1344 Kbit
        Total delay is 20430 microseconds
        Reliability is 255/255
        Load is 8/255
        Minimum MTU is 1500
        Hop count is 5
  10.250.170.106 (Serial1/3:0), from 10.250.170.106, Send flag is 0x0
      Composite metric is (2939904/2427904), Route is Internal
      Vector metric:
        Minimum bandwidth is 1344 Kbit
        Total delay is 40440 microseconds
        Reliability is 255/255
        Load is 10/255
        Minimum MTU is 1500
        Hop count is 7
  10.250.170.217 (Hssi5/0), from 10.250.170.217, Send flag is 0x0
      Composite metric is (2467840/2425088), Route is Internal
      Vector metric:
        Minimum bandwidth is 1344 Kbit
        Total delay is 22000 microseconds
        Reliability is 255/255
        Load is 8/255
        Minimum MTU is 1500
        Hop count is 6
  10.250.170.133 (Serial3/1), from 10.250.170.133, Send flag is 0x0
      Composite metric is (2434816/2429696), Route is Internal
      Vector metric:
        Minimum bandwidth is 1344 Kbit
        Total delay is 20710 microseconds
        Reliability is 255/255
        Load is 8/255
        Minimum MTU is 1500
        Hop count is 8

Richard Burts Wed, 06/30/2010 - 11:17

Thanks for the additional output. It is certainly different from what I expected to see
It is showing that there is not a topology entry for a prefix received from router B. So something does seem to be preventing the advertisements.

I see that there is not a bandwidth statement on the multilink interfaces. I wonder if the behavior would change if you configured a bandwidth statement on each of the multilink interfaces.

I also wonder about this:service-policy output UDN-EDGE

Could you post the configurations related to this service policy?

HTH

Rick

bssmith10 Wed, 06/30/2010 - 11:32

You feel my pain ;-).  Below are the configs associated with the service-policy.

class-map match-any BULK-DATA
match ip dscp af11  af12
match access-group name BULK-DATA
class-map match-all VOICE
match protocol rtp
match access-group name VOICE
class-map match-any MISSION-CRITICAL-DATA
match ip dscp af31
match access-group name MISSION-CRITICAL-DATA
class-map match-any ROUTING
match ip dscp cs6
class-map match-any NET-MGMT
match ip dscp cs2
match protocol snmp
match protocol syslog
match protocol telnet
match protocol dns
match protocol icmp
match protocol ldap
match protocol ntp
match access-group name NET-MGMT
class-map match-any TRANSACTIONAL-DATA
match ip dscp af21  af22
match protocol citrix
match access-group name TRANSACTIONAL-DATA
!        
!        
policy-map UDN-EDGE
class VOICE
  priority percent 10
class ROUTING
  bandwidth percent 2
class NET-MGMT
  bandwidth percent 4
class MISSION-CRITICAL-DATA
  bandwidth percent 7
  random-detect
class TRANSACTIONAL-DATA
  bandwidth percent 5
class BULK-DATA
  bandwidth percent 10
  random-detect
class class-default
  fair-queue
  random-detect

!

ip access-list extended BULK-DATA
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit ip any host 131.89.2.75
permit tcp any any eq 115
permit ip any host 10.210.16.13
permit ip any host 10.210.16.14
ip access-list extended MISSION-CRITICAL-DATA
permit ip any host 131.89.93.71
permit ip any host 131.89.93.72
permit ip any host 131.89.93.73
permit ip any host 10.210.2.141
permit ip any host 10.210.2.142
permit ip host 131.89.93.71 any
permit ip host 131.89.93.72 any
permit ip host 131.89.93.73 any
permit ip host 10.210.2.141 any
permit ip host 10.210.2.142 any
permit ip any 10.246.241.0 0.0.0.255
permit ip any 10.210.12.0 0.0.0.255
ip access-list extended NET-MGMT
permit udp any any eq 9995
ip access-list extended TRANSACTIONAL-DATA
permit tcp any any eq 1521
permit tcp any any eq 3306
permit tcp any any eq 1433
ip access-list extended VOICE
permit udp any any dscp ef
permit udp any any range 16000 56000
permit udp any any range 2200 2400
permit udp any any range 3000 4000
permit udp any any range 45000 46000
permit tcp any any range 2000 2002
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit udp any any eq 4569
permit udp any any eq 5036
permit udp any any eq 5060
permit ip host 10.96.1.54 any
permit ip host 10.96.1.64 any
permit ip host 10.96.1.50 any
permit ip host 10.96.1.51 any
permit ip host 10.96.1.52 any
permit ip host 10.96.1.53 any
permit ip host 10.96.1.60 any
permit ip host 10.96.1.61 any
permit ip host 10.96.1.62 any
permit ip host 10.96.1.63 any
permit ip any 237.0.0.0 0.255.255.255
permit ip any 239.0.0.0 0.255.255.255

Richard Burts Wed, 06/30/2010 - 12:13

Thanks for the additional information. I wonder if the service policy is impacting EIGRP. Would you post the output of show service-policy Multilink203386

I am wondering about this part of the service policy
class ROUTING
  bandwidth percent 2

I wonder what would happen if (as a test) you remove this and let the routing traffic be processed as part of class-default

HTH

Rick

bssmith10 Wed, 06/30/2010 - 12:28

We know the service-policy is not causing the issue.  Identical policy with identical class-maps/ACLs are on all routers and this is the only problem area.

sh policy-map int mu203386
Multilink203386

  Service-policy output: UDN-EDGE

Class-map: ROUTING (match-any)
      2906129 packets, 354356812 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs6 (48)
        2906129 packets, 354356812 bytes
        5 minute rate 0 bps
      Queueing
        Output Queue: Conversation 265
        Bandwidth 2 (%)
        Bandwidth 61 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 323136/68962545
        (depth/total drops/no-buffer drops) 0/0/0

Richard Burts Wed, 06/30/2010 - 13:02

Thanks for the additional information. It sure does look like the service policy is not the cause of the problem.

I have another idea to suggest. On router A do show ip eigrp events. This displays the event log from EIGRP. It may or may not have something that points to the problem, but it establishes a baseline for what is happening in the router. Then on router A do a clear ip eigrp for the neighbor router B. After doing the clear on the neighbor do another show ip eigrp events. This should contain events as the neighbor relationship was re-established and hopefully will point to what the issue may be.

HTH

Rick

bssmith10 Wed, 06/30/2010 - 13:39

The event logs shows Router A ignoring the networks advertised from Router B.  Why it is ignoring a better metric is the mystery.  Below is a snipet from the log.  As expected it is ignoring networks that should be coming from other interfaces, but also the directly attached networks from Router B.

clear ip eigrp neighbors 10.250.241.65
sh ip eigrp event
Event information for AS 2013:
12   13:28:35.817 Ignored route, metric: 10.168.2.250/32 966656
13   13:28:35.817 Ignored route, metric: 10.168.2.254/32 966656
14   13:28:35.817 Ignored route, metric: 10.168.2.253/32 966656
17   13:28:35.817 Ignored route, metric: 10.168.2.244/30 966656
19   13:28:35.817 Ignored route, metric: 10.168.1.0/24 838656
20   13:28:35.817 Ignored route, metric: 10.190.5.0/28 838656
22   13:28:35.817 Ignored route, metric: 10.245.103.0/24 838656
30   13:28:35.797 Ignored route, metric: 10.245.210.0/24 4294967295
31   13:28:35.797 Ignored route, metric: 10.249.100.20/30 4294967295
32   13:28:35.797 Ignored route, metric: 10.245.162.0/24 4294967295
33   13:28:35.797 Ignored route, metric: 10.250.140.172/30 4294967295
34   13:28:35.797 Ignored route, metric: 10.250.140.20/30 4294967295

griffijo@elizab... Wed, 06/30/2010 - 16:54

This is slightly off topic, but why do you need a class for your IGP?  That

is taken care of by PAK_priority.

Richard Burts Wed, 06/30/2010 - 18:16

Thank you for the additional information. The output of show ip eigrp event does confirm that the router is ignoring the advertised routes. But so far it is not providing much insight into why. I wonder if we could get the event log at the time that the neighbor was cleared if there might be a more helpful message. (note in eigrp events the most recent events are at the top and the older events are at the bottom of what is displayed.

And while I am fishing for clues I wonder if you would post the output of show ip protocol from both routers.

HTH

Rick

Richard Burts Wed, 06/30/2010 - 19:01

Your original post contained highly abreviated output from show ip protocol. I would like to see the complete output of show ip protocol.

And as I think about it I would also ask that you post the output of show ip eigrp neighbor detail from both routers.

HTH

Rick

bssmith10 Thu, 07/01/2010 - 08:05

Below are the ip porotocols and neighbor details you asked for.  Last night I tried to force Router A to accept the routes from Router B by using a distribution-list on Router B's other outbound interface to stop one of the internal routes (10.168.2.253/32).  Router A lost the route to that network but still would not install the route from Router B.  Wonder if I am looking at a bug.

Router A

sh ip proto
Routing Protocol is "eigrp 2013"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 2013
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.250.170.114        90      00:20:16
    10.250.170.106        90      00:20:15
    10.250.170.217        90      00:20:15
    10.250.170.202        90      00:20:16
    10.250.110.53         90      00:20:15
    10.250.170.154        90      00:20:16
    10.250.100.93         90      00:20:15
    10.250.170.150        90      10w5d
    10.250.170.133        90      00:20:15
  Distance: internal 90 external 170

!

sh ip eigrp nei det
IP-EIGRP neighbors for process 2013
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
7   10.250.241.65           Mu203386          12 17:40:57    1   200  0  4679
   Version 12.4/1.2, Retrans: 0, Retries: 0
6   10.250.170.154          Mu205680          13 6w4d        1   200  0  84450
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 37
4   10.250.170.106          Se1/3:0           11 6w4d        6   200  0  586698
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2125
5   10.250.170.114          Mu204840          11 10w2d       2   200  0  1507185
   Version 12.4/1.2, Retrans: 15, Retries: 0, Prefixes: 36
1   10.250.100.93           Se6/1             12 14w4d       1   200  0  4213915
   Version 12.2/1.2, Retrans: 3, Retries: 0, Prefixes: 1988
8   10.250.170.217          Hs5/0             12 14w5d       5   200  0  349231
   Version 12.2/1.2, Retrans: 4, Retries: 0, Prefixes: 1071
0   10.250.170.202          Se6/0             10 15w3d       1   200  0  2249060
   Version 12.4/1.2, Retrans: 5, Retries: 0, Prefixes: 40
2   10.250.110.53           Se3/0             13 17w6d       1   200  0  5447192
   Version 12.2/1.2, Retrans: 1, Retries: 0, Prefixes: 1999
3   10.250.170.133          Se3/1             13 40w3d       1   200  0  2685439
   Version 12.4/1.2, Retrans: 119, Retries: 0, Prefixes: 2005

Router B

sh ip prot
Routing Protocol is "eigrp 2013"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 2013
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Passive Interface(s):
    GigabitEthernet0/0
    GigabitEthernet0/1
    Serial0/0/1:0
    Serial0/1/0:0
    GigabitEthernet1/0
    GigabitEthernet1/0.50
    GigabitEthernet1/0.66
    GigabitEthernet1/0.298
    Loopback256
    VoIP-Null0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.250.130.69         90      00:21:16
    10.250.241.66         90      00:21:16
    10.168.1.3            90      00:21:16
    10.168.1.11           90      00:21:16
    10.168.1.10           90      00:21:16
    10.168.1.9            90      00:21:16
  Distance: internal 90 external 170

!

sh ip eigrp nei det
IP-EIGRP neighbors for process 2013
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.250.241.66           Mu203386          13 17:41:58    1   200  0  3060402
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2122
5   10.168.1.3              Gi1/0.300         10 18:13:11    1   200  0  894
   Version 12.4/1.2, Retrans: 2, Retries: 0, Prefixes: 5
0   10.168.1.10             Gi1/0.300         14 18:13:15    1   200  0  968
   Version 12.4/1.2, Retrans: 2, Retries: 0, Prefixes: 1
4   10.250.130.69           Se0/0/0:0         11 1d13h       1   200  0  533773
   Restart time 13:28:08
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2112
2   10.168.1.11             Gi1/0.300         10 1d13h       1   200  0  62585
   Version 12.4/1.2, Retrans: 6, Retries: 0, Prefixes: 1
1   10.168.1.9              Gi1/0.300         14 1d13h       2   200  0  62744
   Version 12.4/1.2, Retrans: 7, Retries: 0, Prefixes: 1

Richard Burts Thu, 07/01/2010 - 17:45

Thanks for the additional information. I do not see anything that explains why the problem is happening.

I do not know if another attempt to clear the neighbor and then show ip eigrp event trying to get the display of events at the moment of the clearing would show anything useful. But it might be worth a try.

I would also suggest that it might be worth doing an interface shutdown/no shutdown on the multilink on router A. I have seen some situations where a routing protocol got confused or otherwise out of sync with its neighbor and a shut/no shut cleared it up. And the ultimate extension of that would be to schedule a reload of the router.

Since we are not making good progress in resolving this it might also be time to be thinking about opening a Cisco TAC case. Are these routers covered under maintenance?

HTH

Rick

bssmith10 Thu, 07/01/2010 - 17:51

I did open a TAC earlier today.  At this point I am going to wait for Cisco to respond.  Rebooting of the router is going to require an outage request, scheduled two weeks out.

Richard Burts Thu, 07/01/2010 - 21:43

I recognize that planning for a reload may require planning and effort (and administrative overhead) which produce delay. I only lay it out as one of the possibilities to consider.

Opening a case with TAC was a good thing. When you get a response or when you have found a solution to the problem please post back to the forum and update us. We would very much like to know how this turns out.

HTH

Rick

bssmith10 Fri, 07/02/2010 - 07:51

I will definately update the forum when the solution is found.  Appreciate your time

on this.

bssmith10 Fri, 07/02/2010 - 13:18

The problem has been resolved, though I still don't know what caused it.  I pulled one of the t1 from the ppp link, gave it an ip address, and established an eigrp neighbor relation over the link.  This immediately saw proper routing as it now had a better metric.  I then blew away the mlppp configuration and rebuilt it.  Once I removed the ip address from the t1 and put it back into the ppp link, we saw Router A accepting routes from Router B.

Correct Answer
Richard Burts Sat, 07/03/2010 - 11:04

I am glad that you have got the problem resolved. Thanks for posting back to the forum about it. Perhaps you could mark the question as solved. This would benefit other people who might read the thread to find out about the problem and about its solution.

Your solution of removing and rebuilding the multilink configuration is a stronger action but similar to my suggestion about interface shutdown/no shutdown. As I commented in a previous post I have seen situations where a routing protocol got confused or out of sync about a neighbor (sometimes it seems related to a configuration change made and then removed where the protocol seems to be remembering the change even though it is no longer in the running config, and sometimes we never had a clue what caused it) and terminating and rebuilding the neighbor relationship would solve the issue.

So congratulations on getting your problem resolved.

HTH

Rick

Actions

This Discussion