Hello Jeff,
it might be only a typing error but interface gi1/2 on routerB appears to be configured for speed 100 and other side for speed 1000 Mbps. However, if this would be true the link should stay down and routing protocol exchanges should not happen. So I will assume both physical ports are running at the same speed.
Analyzing the log files that are more detailed on the C4948 side we see that:
EIGRP neighbor 192,168.225.11 sends two EIGRP hello in roughly 5 seconds (there is a random offset to avoid synchronization)
>>>May 3 16:53:37.615: EIGRP: Received HELLO on Vlan225 nbr 192.168.225.11
>>>May 3 16:53:41.903: EIGRP: Received HELLO on Vlan225 nbr 192.168.225.11
However, no other hello or packet is received from 192.168.225.11 for the next 15 seconds
RouterB (C4948) detects this and declares the neighbor down (notice that the log message uses a different timezone then debug messages)
May 3 11:53:56.904 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.225.11 (Vlan225) is down: holding time expired
May 3 16:53:56.904: EIGRP: Lost Version2 Peer (2 Peers, 1 V2 Peers)
May 3 16:53:56.908: EIGRP: Build goodbye tlv for 192.168.225.11
On the other side on router A it looks like that EIGRP good byes messages are received from time to time from router B ( to be noted the debug messages are related to a different time or a different time zone is configured on router A)
2012 May 3 13:52:19.373 RSCWRNI01 %EIGRP-5-NBRCHANGE_DUAL: eigrp-100 [8161] (d
efault-base) IP-EIGRP(0) 100: Neighbor 192.168.225.13 (Vlan225) is down: Peer go
odbye received
2012 May 3 13:52:23.358 RSCWRNI01 %EIGRP-5-NBRCHANGE_DUAL: eigrp-100 [8161] (d
efault-base) IP-EIGRP(0) 100: Neighbor 192.168.225.13 (Vlan225) is up: new adjac
ency
We can say that RouterA the Nexus is running EIGRP version 2 (newer then version running on RouterB) when the hold timer expires it is declared dead so the message
EIGRP: Lost Version2 Peer (2 Peers, 1 V2 Peers).
It is interesting to note what happens after this event from routerB point of view.
we don't see a goodbye packet sent so it should be checked if the goodbye tLV can travel into an EIGRP hello packet (likely).
This has to be checked. Actually a goodbye message is an Hello message with appended a goodbye TLV so no dedicated packet is needed for sending out the goodbye message.
see
http://www.google.com/patents/US20040258002
What is interesting is that RouterA behaves as it hasn't received any goodbye and sends out one EIGRP query that is received by router B but ignored because the neighbor is not in operational state from its point of view.(= not found)
May 3 16:53:56.988: EIGRP: Received QUERY on Vlan225 nbr 192.168.225.11
May 3 16:53:56.988: AS 100, Flags 0x0:(NULL), Seq 86107/0 interfaceQ 0/0
May 3 16:53:56.988: EIGRP: Neighbor(192.168.225.11) not yet found
later RouterA sends updates with init flag:
May 3 16:54:01.796: EIGRP: Received UPDATE on Vlan225 nbr 192.168.225.11
May 3 16:54:01.796: AS 100, Flags 0x1:(INIT), Seq 86112/0 interfaceQ 0/0
May 3 16:54:01.796: EIGRP: Neighbor(192.168.225.11) not yet found
May 3 16:54:03.816: EIGRP: Received UPDATE on Vlan225 nbr 192.168.225.11
May 3 16:54:03.816: AS 100, Flags 0x1:(INIT), Seq 86112/0 interfaceQ 0/0
May 3 16:54:03.816: EIGRP: Neighbor(192.168.225.11) not yet found
After some seconds RouterA sends a regular EIGRP hello and this is accepted and EIGRP neighborship is rebuilt
May 3 16:54:10.516: EIGRP: Received HELLO on Vlan225 nbr 192.168.225.11
May 3 16:54:10.516: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0
May 3 16:54:10.516: EIGRP: Adding Version2 Peer (2 Peers, 2 V2 Peers)
May 3 11:54:10.516 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.225.11 (Vlan225) is up: new adjacency
you can also see the message EIGRP: Adding Version2 Peer (2 Peers, 2 V2 Peers.
Then a long phase of update exchanges is started as new neighborship requires synchronization of peers.
During this phase there is some misunderstanding and few updates sourced by RouterA are not accepted like:
May 3 16:54:11.428: EIGRP: Received UPDATE on Vlan225 nbr 192.168.225.11
May 3 16:54:11.428: AS 100, Flags 0x2:(CR), Seq 86119/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2, not in CR-mode, packet discarded
most of these messages are sent reliably = in unicast mode and require an ack from receiver that is again a unicast message.
EIGRP can send updates in unreliable mode using multicast if all peers in segment are aligned, if some peer does not answer timely with an ACK the update is resent in unicast mode to the specific peer.
the message
May 3 16:54:11.536: EIGRP: Vlan225 multicast flow blocking cleared
should refer to moving again to multicast updates for example
May 3 16:54:11.600: EIGRP: Sending UPDATE on Vlan225 tid 0
May 3 16:54:11.600: AS 100, Flags 0x0:(NULL), Seq 88884/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 370425-370433
May 3 16:54:11.648: EIGRP: Received ACK on Vlan225 nbr 192.168.225.11
May 3 16:54:11.648: AS 100, Flags 0x0:(NULL), Seq 0/88884 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
May 3 16:54:11.676: EIGRP: Received ACK on Vlan225 nbr 192.168.225.12
May 3 16:54:11.676: AS 100, Flags 0x0:(NULL), Seq 0/88884 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
May 3 16:54:11.676: EIGRP: Vlan225 multicast flow blocking cleared
At time 16:54:26 again RouterB detects hold timer expired but this time for both neighbors!
May 3 11:54:26.656 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.225.11 (Vlan225) is down: holding time expired
May 3 16:54:26.656: EIGRP: Lost Version2 Peer (2 Peers, 1 V2 Peers)
May 3 16:54:26.664: EIGRP: Build goodbye tlv for 192.168.225.11
May 3 16:54:26.664: EIGRP: Sending HELLO on Vlan225
May 3 16:54:26.664: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
May 3 16:54:26.672: EIGRP: Enqueueing UPDATE on Vlan225 tid 0 iidbQ un/rely 0/1 serno 370434-370435
May 3 16:54:26.676: EIGRP: Sending UPDATE on Vlan225 tid 0
May 3 16:54:26.676: AS 100, Flags 0x0:(NULL), Seq 88885/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 370434-370435
May 3 11:54:26.676 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.225.12 (Vlan225) is down: holding time expired
and all the sequence of events restart
It looks like there is some misunderstanding from time to time between RouterB and RouterA
what IOS version is running on the C4948?
the other peer 192.168.225.12 in vlan 225 what kind of device is?
At OSI layer2 there is normal STP activity? because for example STP recalculation could cause EIGRP to flap
Hope to help
Giuseppe
