Neighbor Unreachability Detection

If a node to which another is communicating fails, it is not very beneficial to detect the failure before the upper layers do. If a router in the path to the destination fails, however, there may be an alternative router to use, and it would be extremely helpful to be able to detect that failure before the upper-layer protocol does.

Neighbor reachability is verified in one of two ways—from hints from the upper-layer protocols or from responses to Neighbor Solicitations. Forward-direction communication must be possible for a neighbor to be reachable. Reachability is verified if forward progress is being made by an upper-layer protocol. If forward progress is being made in a TCP connection, for example, as indicated by new acknowledgements being received for data sent or by new data being received in response to a sent acknowledgement, reachability is verified. If forward progress is being made end to end, it also is being made to the next-hop router, and reachability to the router is confirmed.

Some upper-layer protocols do not provide such hints, such as UDP communications. If no verification can be received from upper-layer protocols, the node actively probes neighbors to determine their reachability state. A node sends Neighbor Solicitations to the cached link layer address of the neighbor in question and waits for Neighbor Advertisements. A node sends a Neighbor Advertisement with the solicited bit set only if it received a Neighbor Solicitation. If a node receives a Neighbor Advertisement with the solicited bit set, the node can be certain that its neighbor received the NS that it sent, and therefore forward-direction communication exists. These probes are sent in conjunction with traffic. If no traffic is being sent to a node, no probes are sent to the node.

A neighbor cache stores information about neighbors, including the IP address, link layer address, and reachability state. Table 8-9 lists the possible reachability states.

Table 8-9 Neighbor Reachability States

Table 8-9 Neighbor Reachability States

State	Description
INCOMPLETE	Address resolution is in progress. An NS has been sent, but no reply has yet
	been received.
REACHABLE	Forward-direction communication has been verified within the past 30
	seconds. %
STALE	An entry in the neighbor cache has not been verified as reachable within the
	past 30 seconds. An unsolicited Neighbor Advertisement message will add
	an entry to the cache for the sender of the message, with state STALE. No
	action is required until traffic is sent to the STALE entry.
DELAY	No reachable verification has been received within the past 30 seconds, and
	a packet has been sent to the specified neighbor within the past 5 seconds.
	If no positive confirmation is received within 5 seconds of entering DELAY
	state, send an NS and change the state to PROBE.
PROBE	An NS has been sent to verify reachability. No NA has yet been received.

An entry in the neighbor cache is INCOMPLETE initially. After the link layer address for the entry has been learned, and forward-direction communication has been verified, the state changes to REACHABLE. The state remains REACHABLE as long as the forward direction communication continues to be verified.

When no reachability confirmation is received from a REACHABLE neighbor, its state changes to STALE. An unsolicited RA or NA received from a node puts an INCOMPLETI ! entry into the neighbor cache, which immediately transitions to STALE. An unsolicited advertisement does not provide any information about forward communication. The entries remain STALE until traffic is sent to that neighbor.

As soon as a packet is sent to the neighbor, its state changes to DELAY, and a timer is sel to 5 seconds in the neighbor cache for the entry. The packet is sent to the cached link layer address, even though it is STALE. If the timer expires before any reachability confirmation is received, the state changes to PROBE. If reachability is confirmed, the state changes to REACHABLE.

Upon entering PROBE state, an NS is sent to the cached link layer address of the neighbor. Solicitations continue to be sent every second in the absence of a response, even if no additional data packets are sent. If no response is received for 1 second after three solicitations have been sent, the entry should be deleted from the cache.

Example 8-3 shows output from the debug ipv6 icmp and debug ipv6 nd commands and shows a router's neighbor cache state going from INCOMPLETE to REACHABLE, through all the intermediate states. Example 8-3 also displays the output from the show ipv6 neighbor command, which displays the neighbor cache. The output of the show ipv(> neighbor command provides the IPv6 address, its age, its link layer address (if known), ils state, and the interface through which it is known.

Example 8-3 debug Output Showing Neighbor Reachability State Changes

Example 8-3 debug Output Showing Neighbor Reachability State Changes

Falcon#debug ipv6 icmp
ICMP packet debugging is on
Falcon#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
10:58:08: ICMPv6-	-ND:	Received RA from FE80::200:CFF:FE76:5B7C on
Ethernet010:58:	:08:	ICMPv6-ND: INCMP created: FE80::200:CFF:FE76:5B7C
10:58:08: ICMPv6-	■ND:	INCMP -> STALE: FE80::200:CFF:FE76:5B7C
Falcon#show ipv6 nei
IPv6 Address		Age MAC Address State Interface
FE80: : 200 :CFF:FE76:5B7C 2 0000.0c76.5b7c STALE Ethernet©
11:01:13: ICMPv6:	: Received echo request from FE80::200:CFF:FE76:5B7C
11:01:13: ICMPv6:	: Sending echo reply to FE80::200:CFF:FE76:5B7C
11:01:13: ICMPv6-	•ND:	STALE -> DELAY: FE80::200:CFF:FE76:5B7C
11:01:19: ICMPv6-	■ND:	DELAY -> PROBE: FE80::200:CFF:FE76:5B7C
11:01:19: ICMPv6-	■ND:	Sending NS for FE80::200:CFF:FE76:5B7C on Ethernet©
11:01:19: ICMPv6-	■ND:	Received NA for FE80::200:CFF:FE76:5B7C on Ethernet©
from FE80: :200:	: CFF :	:FE76:5B7C
11:01:19: ICMPv6-	■ND:	PROBE -> REACH: FE80::200:CFF:FE76:5B7C
Falcon#show ipv6	nei
IPv6 Address		Age MAC Address State Interface
FE80: : 200 :CFF:FE76:5B7C 0 0000.0c76.5b7c REACH Ethernet©

Falcon receives an RA from Eagle's link-local address FE80::200:CFF:FE76:5B7C. An INCOMPLETE entry is created in Falcon's cache, which immediately turns STALE, because the RA is unsolicited. At this point, the neighbor cache is queried. The entry does indeed say the address is STALE. Eagle's link layer address is known.

A couple of minutes later, Eagle pings Falcon, as shown by the received echo request. Falcon replies to Eagle, sending the echo response to the stored link layer. Because a packet is forwarded by the router to a STALE entry, however, the router must change the state to DELAY to see whether it can verify the forward-direction communication path. The router cannot verify this with ICMP packets. So it changes the state to PROBE and sends an NS to see whether it can get reachability verification by probing Eagle. Eagle sends an NA. The debug does not show that the solicited bit is set in the NA. After receiving the NA and verifying communication, Falcon changes the state of Eagle's entry to REACH.

The neighbor unreachability detection process enables a host to redirect traffic to an alternative router if its default router fails. It detects the failure of the default router and then chooses another router to which to forward its traffic. Potentially, this can all occur before the upper-layer protocol or application times out. IPv4 hosts might never detect that the default router has failed. An upper-layer protocol or application will time out if the router

fails. The IPv4 host will likely attempt to use the dead router to reestablish a connection. Some IPv4 hosts might know of multiple default routers and could choose the second router through which to reestablish the connection.

Continue reading here: Case Study Default Router Failure and Communication Recovery

Was this article helpful?

+5 -2