Forwarding Traffic Down Tunnels with Autoroute

Autoroute is fairly detailed. Its behavior is intuitive, but you might have to stare at it for a while to understand why you need it. This section explains not only how it works, but also why you need it.

If you bring up most types of interfaces in Cisco IOS Software (a physical interface, subinterface, or GRE tunnel), you need to enable your Interior Gateway Protocol (IGP) on that interface in order to form routing protocol adjacency, learn routes, and build a routing table involving that interface. If you don't do this, you won't be able to dynamically figure out what traffic to send down that interface. Of course, you can point static routes down an interface without running your IGP on that interface, but that's not germane to this discussion.

You've probably noticed that enabling your IGP on a TE tunnel interface has not been mentioned. This is not an accidental omission; this step was left out on purpose. One of the attractive scaling properties of MPLS TE is that, unlike most other types of interfaces, you do not run an IGP over an MPLS TE tunnel. Two reasons for this are

• TE tunnels are unidirectional and thus can never receive any packets. If an interface can't receive any packets (such as routing updates), it's difficult to run an IGP over it.

• You don't need it. Because TE tunnels often originate and terminate in the same area, and because you already have the full link-state topology for that area, you don't need to flood another copy of the area's routing information (IS-IS LSPs or OSPF LSAs) over the tunnel. You'll get all the IGP information flooded over the underlying physical topology anyway, so there's no need to reflood over the TE tunnel.

Running a TE tunnel across multiple areas was covered in detail in Chapter 4.

The fact that you don't run a routing protocol over a TE interface has some attractive scaling properties, as you'll see later in Chapter 9, "Network Design with MPLS TE," and Chapter 10, "MPLS TE Deployment Tips." Not running a routing protocol over a TE interface also means that you need some other way of telling the router to provide the equivalent behavior. What you need is a knob that tells the tunnel headend the following:

Treat this interface like the tunnel is a directly connected link to the tunnel tail, and send any packets down the tunnel that are destined for either the tunnel's tail or anything behind that tunnel tail.

The MPLS TE autoroute feature does precisely that. The basic configuration is simple: tunnel mpls traffic-eng autoroute announce on the tunnel headend. You can apply a few options to autoroute, as you will see in the section "How to Play with the TE Tunnel Metric."

Autoroute? You might be familiar with a feature in Cisco's IGX/MGX/BPX WAN switch line of equipment called autoroute. That autoroute (a method of determining a path across the network) has nothing to do with the autoroute discussed here. The WAN switch feature called autoroute is similar to the MPLS TE CSPF. It's a method of calculating a path from one point to another point that meets a certain resource requirement.

To get a better grip on how MPLS TE autoroute works, consider Figure 5-2.

The following examples demonstrate the effects that autoroute, static routes, and policy routing have on Router A's routing table. Unless otherwise specified, all links in this network have a cost of 10.

Before TE tunnels are introduced, Router A's routing table looks like Table 5-1.

Table 5-1. Router A's Routing Table Prior to TE Tunnel Configuration

Node	Next Hop	Cost
A	Self	0
B	B	10
C	C	10
D	C	20
E	B	20
F	B	30
G	B	30
H	B	40
I	B	40

After the TE tunnel from Router A to Router E is up, you need to map traffic to Router E to Tunnel0. The effect of static routes on a routing table should be obvious. If you configure a static route for Router G pointing down the tunnel,

ip route   router G's RID    255.255.255.255 Tunnel0

Router A's routing table will look like Table 5-2.

Table 5-2. Router A's Routing Table After a Static Route Is Configured

Node	Next Hop	Cost
A	Self	0
B	B	10
C	C	10
D	C	20
E	B	20
F	B	30
G	Tunnel0	0
H	B	40
I	B	40

Policy routing is arguably even simpler because it doesn't change the routing table at all. Packet forwarding decisions are made based on the configured policy and interface, not the routing table.

Autoroute is where things start to get interesting.

As mentioned earlier, autoroute tells a router to build its routing table so that anything behind the TE tunnel tailend is routed down that tunnel. How does this work? The IGP runs its regular SPF, but if it encounters a node that is either TE tunnel tail or located behind the TE tunnel tail, it installs the TE tunnel to that node rather than to the IGP path in the routing table.

To better understand this, walk through Router A's IGP SPF process, with autoroute enabled on the tunnel to Router E.

Router A starts by putting itself on the PATH list and its neighbors (Routers B and C) on the TENT list, with the following results:

PATH List	TENT List
{A,0,0}	{B,10,B}
	{C,10,C}

The next step is to take Router B from the TENT list, put it on the PATH list, and put Router B's neighbors on the TENT list, with the following results:

PATH List	TENT List
{A,0,0}	{C,10,C}
{B,10,B}	{E,20,B}

Router C is then moved to the PATH list, and its neighbors are put on the TENT list, with the following results:

PATH List	TENT List
{A,0,0}	{E,20,B}
{B,10,B}	{D,20,C}
{C,10,C}

Because the tunnel tail ends on Router E, you replace Router E's next hop of B with Tunnel0. First, moving Router E to the PATH list results in the following:

PATH List	TENT List
{A,0,0}	{D,20,C}
{B,10,B}
{C,10,C}
{E,20,B}

Next, replacing Router E's next hop with the tunnel to Router E results in the following table. Note that the cost to get to the tunnel tail has not changed—only the outgoing interface:

PATH List	TENT List
{A,0,0}	{D,20,C}
{B,10,B}
{C,10,C}
{E,20,Tunnel0}

Then Router E's neighbors are added to the TENT list. When Router E's neighbors (Routers F and G) are put on the TENT list, they are given the next hop used to get to Router E, or Tunnel0:

PATH List	TENT List
{A,0,0}	{D,20,C}
{B,10,B}	{F,30,Tunnel0}
{C,10,C}	{G,30,Tunnel0}
{E,20,Tunnel0}

To finish the SPF process, move {D,20,C} to the PATH list, with the following results:

PATH List	TENT List
{A,0,0}	{F,30,Tunnel0}
{B,10,B}	{G,30,Tunnel0}
{C,10,C}
{E,20,Tunnel0}
{D,20,C}

Router D's only neighbor is Router E, but the cost to get to Router E through Router D is 30, which is higher than the cost to get to Router E on the PATH list. So, moving Router D to the PATH list adds no new nodes to the TENT list.

Move Router F to the PATH list, with the following results:

PATH List	TENT List
{A,0,0}	{G,30,Tunnel0}
{B,10,B}
{C,10,C}
{E,20,Tunnel0}
{D,20,C}
{F,30,Tunnel0}

Router F has no new neighbors, so proceed to Router G, which has two neighbors, Routers H and I, and add them to the TENT list, as follows:

PATH List	TENT List
{A,0,0}	{H,40,Tunnel0}
{B,10,B}	{I,40,Tunnel0}
{C,10,C}
{E,20,Tunnel0}
{D,20,C}
{F,30,Tunnel0}
{G,30,Tunnel0}

Routers H and I have no new neighbors, so they both end up on the PATH list and don't add anything to the TENT list.

Compressing these two steps into one, you end up with the following results:

PATH List	TENT List
{A,0,0}	<empty>
{B,10,B}
{C,10,C}
{E,20,Tunnel0}
{D,20,C}
{F,30,Tunnel0}
{G,30,Tunnel0}
{H,40,Tunnel0}
{I,40,Tunnel0}

This translates into the routing table shown in Table 5-3.

Table 5-3. Router A's Routing Table After the IGP SPF Process, with Autoroute Enabled on the Tunnel to Router E

Node	Next Hop	Cost
A	Self	0
B	B	10
C	C	10
D	C	20
E	Tunnel0	20
F	Tunnel0	30
G	Tunnel0	30
H	Tunnel0	40
I	Tunnel0	40

It's simple. The fundamental thing to understand is that, with autoroute enabled, the tunnel tail is always routed only through the tunnel. Even though Figure 5-2 shows multiple ways to get to Router E, the tunnel is the only route used. This is how the IGP SPF works; the tunnel tail can be reached only through the tunnel because of the replacement of the physical next hop with the tunnel interface during IGP SPF. Nodes behind the tunnel tail can generally be reached through the tunnel, although you can get to a node through both an IGP route and the TE tunnel route in some cases.

You have yet to explore a few subtleties:

• Load sharing between a TE tunnel path and an IGP path

• Load sharing between two TE tunnels

• Changing the metric used for the TE tunnel

The next two sections cover these subtleties, but what's just been covered is most of what you need to know to use autoroute successfully.

Much of what autoroute does is invisible to the user. The only show command autoroute has is show mpls traffic-eng autoroute, which can optionally take the RID of a TE tail as an argument. Example 5-2 shows the output from this command.

Example 5-2 show mpls traffic-eng autoroute Command Output

vxr15#show mpls traffic-eng autoroute

MPLS TE autorouting enabled

  destination 0168.0001.0008.00 has 1 tunnels

    Tunnel20    (traffic share 0, nexthop 192.168.1.8)

                (flags: Announce)

  destination 0168.0001.0011.00 has 3 tunnels

    Tunnel11    (traffic share 11111, nexthop 192.168.1.11)

                (flags: Announce)

    Tunnel12    (traffic share 11111, nexthop 192.168.1.11)

                (flags: Announce)

    Tunnel13    (traffic share 7352, nexthop 192.168.1.11)

                (flags: Announce)

The destination is the IGP RID (in this case, the CLNS NSAP) of the router that is the TE tunnel tail. The traffic share value is nonzero if bandwidth is configured on the TE tunnel and is 1,000,000 divided by the tunnel bandwidth. This traffic share value helps compute load sharing between multiple TE tunnels to the same destination.