blob: 4c1dfe2a07dc0fb332c55e659cc9d8a9593d1fd0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
.. _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 recursive switch 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/fib20fig2.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 ԭid-chainՠthis 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ճ 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, or that the
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 ...).
|
