The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

EIGRP goodbyes

By stretch | Thursday, August 14, 2008 at 9:31 a.m. UTC

EIGRP includes a special type of hello packet, known as a "goodbye." Goodbyes are transmitted by an EIGRP router to its peer whenever a neighbor adjacency fails but the interface to reach that neighbor is still up. This could be the result of administrative reconfiguration, but sometimes the physical link between two EIGRP neighbors will fail without the routers realizing it (the interface status remains up/up).

In this case, the router will continue to transmit hellos (among other data) to the neighbor without receiving any hellos in return until the hold timer expires and the adjacency is torn down. When this happens, a router will transmit a goodbye message as an explicit notification that it is tearing down the adjacency.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.1 (FastEthernet0/0) is down:
Interface Goodbye received

You're likely to wonder what the point of this is if the link to the neighbor has failed. However, goodbyes provide an excellent troubleshooting tool when dealing with links that have only partially failed and have become unidirectional. This is a common scenario with fiber connections, and as I have come to find, with satellite links. Often one satellite station will be receiving from another, but for some reason (such as poor weather) will not be transmitting at a high enough power for its signal to be received by the distant station. When EIGRP is run across such a link, the distant station will tear down the adjacency and transmit a goodbye packet, giving the operator a clear indication of the direction in which the link is still functional.

unidirectional_sat_link.png

The goodbye packet itself is actually a hello packet with all its K values set to 255. An example can be seen in packet #9 of this EIGRP traffic capture.

Posted in

Comments


Paul
August 15, 2008 at 8:02 a.m. UTC

A Cisco router that runs a software release that does not support the goodbye message will misinterpret the message as a K-value mismatch and display the following message:

*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor
10.1.1.1  (Ethernet0/0) is down: K-value mismatch

The goodbye message is supported in Cisco IOS Release 12.3(2), 12.3(3)B, and 12.3(2)T and later releases.

I found this during my BSCI studies :)


Frank
September 26, 2008 at 6:15 p.m. UTC

So, when running a fiber ring w/ Spanning Tree blocking on one of the uplinks (making one of the nodes unidirectional to one of it's neighbors), how do you stabilize the EIGRP process? One node sends goodbyes to it's neighbors, and then the the adjacency immediate syncs back up.


edon
June 13, 2012 at 1:34 p.m. UTC

I've found this happening on DMVPN tunnels for me. I have about 100 sites running bgp through wan and EIGRP through DSL or 3G. I figured 3G connection would have bad signal from time to time and would cause the same problem.

Jun 13 08:25:28.506: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 10.237.4.1 (Tunnel1) is down: Peer goodbye receive

Also this one which drove me crazy.

CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=192.168.2.10, prot=17, spi=0xC8555555(3361035605), srcaddr=x.x.x.x


realdreams
September 21, 2012 at 2:35 a.m. UTC

Another case EIGRP goodbye may be sent is when static neighbor is configured on an interface. As soon as static neighbor is configured, EIGRP Goodbye is sent to all neighbors on this interface. Does EIGRP goodbye use multicast or unicast?


POZ
September 21, 2012 at 4:57 p.m. UTC

I have the same behavior on an att OPT-E-MAN connection between one of our data centers and 3 remote sites, The DC 65K is receiving the EIGRP Goodbye while the other sites only showing holding time expired. The head end (DC) device appears to be receiving ok but the remote sites are not getting the hello keep-alive from the 65k. Since all 3 remote sites holding time expired messages occur at exactly the same time and I see no interface or protocol changes on any device can I then surmise that problem probably lies on the DC service provider side?


David
November 13, 2013 at 4:41 p.m. UTC

This happen to me and the problem was that the subnet were different on both routers. I find out when I was able to ping one way and not the other.


rfc
June 30, 2016 at 8:09 a.m. UTC

Isn't Goodbye message from neighbor graceful shutdown?

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html

A graceful shutdown occurs: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: Interface Goodbye received

Goodbye message is nowhere to be found in RFC7868. Cisco has been changing the behavior or EIGRP without publishing anything about it.


CCIE
August 23, 2016 at 3:53 p.m. UTC

Some routers will show:

Aug 23 12:45:43.183: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.12.2 (Serial1/0) is down: Interface PEER-TERMINATION received

for the same (AKs = 255) message, that can be triggered by different events, like graceful restart, admin proto shutdown or hold T/O.

If you are a real CCIE, you should know which one is the one that triggered it :)

Comments have closed for this article due to its age.