docs/developer/corefeatures/fib/tunnels.rst

   1 .. _tunnels:
   2
   3 Tunnels
   4 -------
   5
   6 Tunnels share a similar property to recursive routes in that after applying the
   7 tunnel encapsulation, a new packet must be forwarded, i.e. forwarding is
   8 recursive. However, as with recursive routes the tunnel's destination is known
   9 beforehand, so the second lookup can be avoided if the packet can follow the
  10 already constructed data-plane graph for the tunnel's destination. This process
  11 of joining to DP graphs together is termed *stacking*.
  12
  13 .. figure:: /_images/fib20fig11.png
  14
  15 Figure 11: Tunnel control plane object diagram
  16
  17 Figure 11 shows the control plane object graph for a route via a tunnel. The two
  18 sub-graphs for the route via the tunnel and the route for the tunnel's
  19 destination are shown to the right and left respectively. The red line shows the
  20 relationship form by stacking the two sub-graphs. The adjacency on the tunnel
  21 interface is termed a 'mid-chain' since it is now present in the middle of the
  22 graph/chain rather than its usual terminal location.
  23
  24 The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes
  25 part of the FIB control-plane graph. Consequently it will be visited by a
  26 back-walk when the forwarding information for the tunnel's destination changes.
  27 This will trigger it to restack the mid-chain adjacency on the new
  28 *load_balance_t* contributed by the parent *fib_entry_t*.
  29
  30 If the back-walk indicates that there is no route to the tunnel's
  31 destination, or that the resolving route does not meet resolution
  32 constraints, then the tunnel can be marked as down, and fast
  33 convergence can be triggered in the same way as for physical interfaces (see section ...).
  34
  35
  36 Multi-Point Tunnels
  37 ^^^^^^^^^^^^^^^^^^^
  38
  39 Multi-point tunnels are an example of a non-broadcast multi-access
  40 interface. In simple terms this means there are many peers on the link
  41 but it is not possible to broadcast a single message to all of them at
  42 once, and hence the usual peer discovery mechanism (as employed,
  43 e.g. by ARP) is not available. Although an *ip_neighbor_t* is a
  44 representation of an IP peer on a link, it is not valid in this
  45 context as it maps the peer's identity to its MAC address. For a
  46 tunnel peer it is required to map the peer's overlay address (the
  47 attached address, the one in the same subnet as the device) with the
  48 peer's underlay address (probably on the other side of the
  49 internet). In the P2P case where there is only one peer on the link,
  50 the peer's underlay address is the same as the tunnel's destination
  51 address.
  52 The data structure that represents the mapping of the peer's overlay
  53 with underlay address is an entry in the Tunnel Endpoint Information
  54 Base (TEIB); the *tieb_entry_t*. TEIB entries are created by the
  55 control plane (e.g. NHRP (RFC2332)).
  56
  57 Each mid-chain adjacency on a multi-point tunnel is stacked on the
  58 *fib_entry_t* object that resolves the peer's underlay address. The
  59 glean adjacency on the tunnel resolves via a drop, since broadcasts
  60 are not possible. A multicast adjacency on a multi-point tunnel is
  61 currently a work in progress.
  62