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

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

%

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

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.

Was this article helpful?

+1 0
100 SEO Tips

100 SEO Tips

100 SEO Tips EVERY SEO Enthusiast Should Know. This Report 100 SEO Tips will help you to Utilize These Tips to Dominate The Search Engine Today.

Get My Free Ebook


Post a comment