diff options
Diffstat (limited to 'docs/gettingstarted/developers/fib20/tunnels.rst')
| -rw-r--r-- | docs/gettingstarted/developers/fib20/tunnels.rst | 62 |
1 files changed, 0 insertions, 62 deletions
diff --git a/docs/gettingstarted/developers/fib20/tunnels.rst b/docs/gettingstarted/developers/fib20/tunnels.rst deleted file mode 100644 index f53d6223589..00000000000 --- a/docs/gettingstarted/developers/fib20/tunnels.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. _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. - |