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