dfd3954c04
Type: docs Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I3dfde4520a48c945ca9707accabbe1735c1a8799
63 lines
3.0 KiB
ReStructuredText
63 lines
3.0 KiB
ReStructuredText
.. _tunnels:
|
|
|
|
Tunnels
|
|
-------
|
|
|
|
Tunnels share a similar property to recursive routes in that after applying the
|
|
tunnel encapsulation, a new packet must be forwarded, i.e. forwarding is
|
|
recursive. However, as with recursive routes the tunnel's destination is known
|
|
beforehand, so the second lookup can be avoided if the packet can follow the
|
|
already constructed data-plane graph for the tunnel's destination. This process
|
|
of joining to DP graphs together is termed *stacking*.
|
|
|
|
.. figure:: /_images/fib20fig11.png
|
|
|
|
Figure 11: Tunnel control plane object diagram
|
|
|
|
Figure 11 shows the control plane object graph for a route via a tunnel. The two
|
|
sub-graphs for the route via the tunnel and the route for the tunnel's
|
|
destination are shown to the right and left respectively. The red line shows the
|
|
relationship form by stacking the two sub-graphs. The adjacency on the tunnel
|
|
interface is termed a 'mid-chain' since it is now present in the middle of the
|
|
graph/chain rather than its usual terminal location.
|
|
|
|
The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes
|
|
part of the FIB control-plane graph. Consequently it will be visited by a
|
|
back-walk when the forwarding information for the tunnel's destination changes.
|
|
This will trigger it to restack the mid-chain adjacency on the new
|
|
*load_balance_t* contributed by the parent *fib_entry_t*.
|
|
|
|
If the back-walk indicates that there is no route to the tunnel's
|
|
destination, or that the resolving route does not meet resolution
|
|
constraints, then the tunnel can be marked as down, and fast
|
|
convergence can be triggered in the same way as for physical interfaces (see section ...).
|
|
|
|
|
|
Multi-Point Tunnels
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
Multi-point tunnels are an example of a non-broadcast multi-access
|
|
interface. In simple terms this means there are many peers on the link
|
|
but it is not possible to broadcast a single message to all of them at
|
|
once, and hence the usual peer discovery mechanism (as employed,
|
|
e.g. by ARP) is not available. Although an *ip_neighbor_t* is a
|
|
representation of an IP peer on a link, it is not valid in this
|
|
context as it maps the peer's identity to its MAC address. For a
|
|
tunnel peer it is required to map the peer's overlay address (the
|
|
attached address, the one in the same subnet as the device) with the
|
|
peer's underlay address (probably on the other side of the
|
|
internet). In the P2P case where there is only one peer on the link,
|
|
the peer's underlay address is the same as the tunnel's destination
|
|
address.
|
|
The data structure that represents the mapping of the peer's overlay
|
|
with underlay address is an entry in the Tunnel Endpoint Information
|
|
Base (TEIB); the *tieb_entry_t*. TEIB entries are created by the
|
|
control plane (e.g. NHRP (RFC2332)).
|
|
|
|
Each mid-chain adjacency on a multi-point tunnel is stacked on the
|
|
*fib_entry_t* object that resolves the peer's underlay address. The
|
|
glean adjacency on the tunnel resolves via a drop, since broadcasts
|
|
are not possible. A multicast adjacency on a multi-point tunnel is
|
|
currently a work in progress.
|
|
|