From: my-ccie-test@libero.it
Date: Sat Feb 12 2005 - 10:49:47 GMT-3
Hi,
from RFC 2461:
5.1. Conceptual Data Structures
Hosts will need to maintain the following pieces of information for
each interface:
.
.
.
Destination Cache
- A set of entries about destinations to which
traffic has been sent recently. The Destination
Cache includes both on-link and off-link
destinations and provides a level of indirection
into the Neighbor Cache; the Destination Cache maps
a destination IP address to the IP address of the
next-hop neighbor. This cache is updated with
information learned from Redirect messages.
Implementations may find it convenient to store
additional information not directly related to
Neighbor Discovery in Destination Cache entries,
such as the Path MTU (PMTU) and round trip timers
maintained by transport protocols.
.
.
Default Router List
- A list of routers to which packets may be sent.
Router list entries point to entries in the
Neighbor Cache; the algorithm for selecting a
default router favors routers known to be reachable
over those whose reachability is suspect. Each
entry also has an associated invalidation timer
value (extracted from Router Advertisements) used
to delete entries that are no longer advertised.
.
.
.
When sending a packet to a destination, a node uses a combination of
the Destination Cache, the Prefix List, and the Default Router List
to determine the IP address of the appropriate next hop, an operation
known as "next-hop determination". Once the IP address of the next
hop is known, the Neighbor Cache is consulted for link-layer
information about that neighbor.
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packets destination is on- or
off-link. If the destination is on-link, the next-hop address is the
same as the packets destination address. Otherwise, the sender
selects a router from the Default Router List (following the rules
described in Section 6.3.6). If the Default Router List is empty,
the sender assumes that the destination is on-link.
For efficiency reasons, next-hop determination is not performed on
every packet that is sent. Instead, the results of next-hop
determination computations are saved in the Destination Cache (which
also contains updates learned from Redirect messages). When the
sending node has a packet to send, it first examines the Destination
Cache. If no entry exists for the destination, next-hop
determination is invoked to create a Destination Cache entry.
Once the IP address of the next-hop node is known, the sender
examines the Neighbor Cache for link-layer information about that
neighbor. If no entry exists, the sender creates one, sets its state
to INCOMPLETE, initiates Address Resolution, and then queues the data
packet pending completion of address resolution. For multicast-
capable interfaces Address Resolution consists of sending a Neighbor
Solicitation message and waiting for a Neighbor Advertisement. When
a Neighbor Advertisement response is received, the link-layer
addresses is entered in the Neighbor Cache entry and the queued
packet is transmitted.
.
.
.
Each time a Neighbor Cache entry is accessed while transmitting a
unicast packet, the sender checks Neighbor Unreachability Detection
related information according to the Neighbor Unreachability
Detection algorithm (Section 7.3). This unreachability check might
result in the sender transmitting a unicast Neighbor Solicitation to
verify that the neighbor is still reachable.
.
.
Next-hop determination is done the first time traffic is sent to a
destination. As long as subsequent communication to that destination
proceeds successfully, the Destination Cache entry continues to be
used. If at some point communication ceases to proceed, as
determined by the Neighbor Unreachability Detection algorithm, next-
hop determination may need to be performed again. For example,
traffic through a failed router should be switched to a working
router. Likewise, it may be possible to reroute traffic destined for
a mobile node to a "mobility agent".
Note that when a node redoes next-hop determination there is no need
to discard the complete Destination Cache entry. In fact, it is
generally beneficial to retain such cached information as the PMTU
and round trip timer values that may also be kept in the Destination
Cache entry.
.
.
A node should retain entries in the Default Router List and the
Prefix List until their lifetimes expire. However, a node may
garbage collect entries prematurely if it is low on memory. If not
all routers are kept on the Default Router list, a node should retain
at least two entries in the Default Router List (and preferably more)
in order to maintain robust connectivity for off-link destinations.
.
.
A router might want to send Router Advertisements without advertising
itself as a default router. For instance, a router might advertise
prefixes for address autoconfiguration while not wishing to forward
packets. Such a router sets the Router Lifetime field in outgoing
advertisements to zero.
.
.
6.3.6. Default Router Selection
The algorithm for selecting a router depends in part on whether or
not a router is known to be reachable. The exact details of how a
node keeps track of a neighbors reachability state are covered in
Section 7.3. The algorithm for selecting a default router is invoked
during next-hop determination when no Destination Cache entry exists
for an off-link destination or when communication through an existing
router appears to be failing. Under normal conditions, a router
would be selected the first time traffic is sent to a destination,
with subsequent traffic for that destination using the same router as
indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages.
The policy for selecting routers from the Default Router List is as
follows:
1) Routers that are reachable or probably reachable (i.e., in any
state other than INCOMPLETE) SHOULD be preferred over routers
whose reachability is unknown or suspect (i.e., in the
INCOMPLETE state, or for which no Neighbor Cache entry exists).
An implementation may choose to always return the same router or
cycle through the router list in a round-robin fashion as long
as it always returns a reachable or a probably reachable router
when one is available.
2) When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been
selected.
Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability
as a side effect.
3) If the Default Router List is empty, assume that all
destinations are on-link as specified in Section 5.2.
so both routers can ber used as default gateway for your PCs
This archive was generated by hypermail 2.1.4 : Thu Mar 03 2005 - 08:51:20 GMT-3