Manually configured EIGRP neighbor

Unanswered Question
mlasarko Thu, 04/08/2004 - 09:07
User Badges:

Greetings,

To answer your first question; When you define a static EIGRP neighbor the default EIGRP multicast packets (d=224.0.0.10) are no longer sent. The interface only forwards unicast packets once this is configured.


Here's a quick example using 'debug ip packet' along with the following two base configurations (edited for this thread)


Router 'A'


!./

!

hostname A

!

interface FastEthernet0

ip address 1.1.1.10 255.255.255.0

speed auto

!

router eigrp 1

network 1.0.0.0

no auto-summary

!

!./


Router 'B'


!./

!

hostname B

!

interface FastEthernet0

ip address 1.1.1.11 255.255.255.0

speed auto

!

router eigrp 1

network 1.0.0.0

no auto-summary

!

!./


1st, we see the default multicast packets being sent in both directions - our neighbor relationship has been formed:


2d02h: IP: s=1.1.1.11 (FastEthernet0), d=224.0.0.10, len 60, rcvd 2

2d02h: IP: s=1.1.1.10 (local), d=224.0.0.10 (FastEthernet0), len 60, sending broad/multicast

2d02h: IP: s=1.1.1.11 (FastEthernet0), d=224.0.0.10, len 60, rcvd 2

2d02h: IP: s=1.1.1.10 (local), d=224.0.0.10 (FastEthernet0), len 60, sending broad/multicast


Next, if we change one side of this neighbor configuration to static we see the following:


A(config)#router eigrp 1

A(config-router)#neighbor 1.1.1.11 fa0

A(config-router)#end

A#

2d02h: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 1.1.1.11 (FastEthernet0) is down: Static peer configured

2d02h: %SYS-5-CONFIG_I: Configured from console by console

A#


Here's what our current output looks like compliments of 'debug ip packet'


2d02h: IP: s=1.1.1.10 (local), d=1.1.1.11 (FastEthernet0), len 60, sending

2d02h: IP: s=1.1.1.11 (FastEthernet0), d=224.0.0.10, len 60, rcvd 2

2d02h: IP: s=1.1.1.10 (local), d=1.1.1.11 (FastEthernet0), len 60, sending

2d02h: IP: s=1.1.1.11 (FastEthernet0), d=224.0.0.10, len 60, rcvd 2


At this point we have lost our EIGRP neighbors which were previously established... We can do two things here. One option would be to remove the neighbor statement; the other would be to configure a static neighbor on the other side of our link. Since we started with the first option as our default behavior, let's configure the static neighbor on the other side.


B(config)#router eigrp 1

B(config-router)#neighbor 1.1.1.10 fa0

B(config-router)#end

B#

2d02h: %SYS-5-CONFIG_I: Configured from console by console

2d02h: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 1.1.1.10 (FastEthernet0) is up: new adjacency

B#

B#debug ip packet

IP packet debugging is on

B#

2d02h: IP: s=1.1.1.10 (FastEthernet0), d=1.1.1.11 (FastEthernet0), len 60, rcvd 3

2d02h: IP: s=1.1.1.11 (local), d=1.1.1.10 (FastEthernet0), len 60, sending

2d02h: IP: s=1.1.1.10 (FastEthernet0), d=1.1.1.11 (FastEthernet0), len 60, rcvd 3

2d02h: IP: s=1.1.1.11 (local), d=1.1.1.10 (FastEthernet0), len 60, sending


Now our neighbors are happy, engaged in unicast communication, no multicast to be seen, etc...


In response to your second question, regarding "a busy Ethernet segment" more detail would be helpful in order to properly diagnose your particular situation. Static definition of EIGRP neighbors is usually necessary when communicating between VLANs or across links where multicast is not permitted. Considering that EIGRP sends out both unicast and multicast packets at regular intervals if the network is significantly impacted then either means of configuration may be “unstable”. My advice is that if the devices running EIGRP can communicate by way of both multicast and unicast, with all other things being equal (timers, k-values, etc...) you have something else going on that requires attention. A packet capture filtered on the addresses of your EIGRP neighbors may be quite helpful here.


Best,

~M


ruwhite Fri, 04/09/2004 - 03:56
User Badges:
  • Gold, 750 points or more

Another thing that might be useful in this case is the output of eigrp neighbor logging. It would tell us if the neighbors are failing because of stuck in actives, retransmission timeouts, or simple hold timer expirations. The troubleshooting techniques in each one of these cases is different.


:-)


Russ.W

Actions

This Discussion