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
