| jdenisco | 0923a23 | 2018-08-29 13:19:43 -0400 | [diff] [blame] | 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 recursive switch 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/fib20fig2.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 ԭid-chainՠthis 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ճ 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, or that the |
| 31 | route does not meet resolution constraints, then the tunnel can be marked as |
| 32 | down, and fast convergence can be triggered in the same way as for physical |
| 33 | interfaces (see section ...). |