+++ /dev/null
-.. _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.
-
Code Review / vpp.git / blobdiff