## Cost Calculation of IGP Routes over TE Tunnels

Knowing the metric for prefixes with TE tunnels as next hop might not be as straightforward as you think. This section explains how to calculate the cost of the prefixes with TE tunnels as the next hop, each time with autoroute announce enabled on the tunnel interface. When you are using autoroute announce, the cost of the TE tunnel as used by the IGP for the prefixes with the TE tunnel as next hop is always the lowest IGP total cost of the path. This cost is the path weight you see under Shortest Unconstrained Path Info when looking at a TE tunnel. The only exception to this is when you use TE metrics. See the earlier section "Dual TE Metrics" for more on this.

Default Cost Calculation

Figure 8-23 shows a network of five OSPF routers in one MPLS TE-enabled area. All links have an OSPF cost of 1 to start.

Figure 8-23 Tunnel to Router Paris

Loopback 0 10.200.254.5/32

Loopback 0 10.200.254.6/32

berlin berlin

OSPF Cost 1

rome

brussels brussels o U

Loopback 0 10.200.254.3/32

10.200.212.1

10.200.212.2

0.Loopback 0 10.200.254.4/32

frankfurt

OSPF Cost 1

paris x.

rome

A TE tunnel exists from router berlin to router paris. The cost of the TE tunnel is 2. Because 10.200.254.2/32 is directly connected to router paris, the cost or metric for this route in the routing table of router berlin is 3. Notice in Example 8-26 that the tunnel interface on router berlin is the only next hop for that prefix. The cost via the IP path berlin-brussels-paris is also 2, but this IP path is not installed in the routing table. The general rule is that for a prefix on the tail end router, only a tunnel that ends on that tail end router is used to forward packets. No load balancing occurs between the TE tunnel and the IP path in this case. Even if the TE tunnel is not on the lowest IGP cost path (it might have an explicit path that is not on the shortest path, or it might be waiting to be reoptimized), all traffic that is destined for prefixes connected to the tail end router goes into the TE tunnel. The TE tunnel and prefix 10.200.254.2/32 are shown in Example 8-26.

Example 8-26 TE Tunnel from Router Berlin to Router Paris berlin#show mpls traffic-eng tunnels tunnel 1

Name: berlin_t1 (Tunnel1) Destination: 10.200.254.2

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, type dynamic (Basis for Setup, path weight 2) Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters:

State: dynamic path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -OutLabel : POS0/1, 18 RSVP Signalling Info:

Src 10.200.254.5, Dst 10.200.254.2, Tun_Id 1, Tun_Instance 1 RSVP Path Info:

Explicit Route: 10.200.211.1 10.200.210.1 10.200.254.2 Record Route: NONE

Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info:

Record Route: NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 2 (TE)

Explicit Route: 10.200.211.1 10.200.210.1 10.200.254.2 berlin#show ip route 10.200.254.2 255.255.255.255

Routing entry for 10.200.254.2/32

Known via "ospf 1", distance 110, metric 3, type intra area Routing Descriptor Blocks: * directly connected, via Tunnel1

Route metric is 3, traffic share count is 1

Now you will change the tunnel destination to 10.200.254.4, which is the router frankfurt. If you change the link berlin-brussels to an OSPF cost 3, the dynamic TE tunnel reoptimizes to the path berlin-rome-frankfurt and has a cost of 2. You can see this in Figure 8-24.

Figure 8-24 Tunnel to Router Frankfurt

Loopback 0 10.200.254.5/32

berlin

OSPF Cost 1

Loopback 0 10.200.254.3/32

brussels ^a/

OSPF Cost 1

paris

Loopback 0 10.200.254.6/32 ^

TE Tunnel 1 (Cost 2)

Loopback 0 " 10.200.254.4/32

frankfurt rome

However, two paths now go to router paris. One is the IP path berlin-brussels-paris with a cost of 4, and one is the path tunnel 1{berlin-rome-frankfurt}-brussels-paris with a total cost of 2 + 1 + 1 = 4. That means that prefix 10.200.254.2/32 has two next hops in the routing table: tunnel 1 and 10.200.211.1 (brussels). As you can see in Example 8-27, for a prefix behind the tail end router of a TE tunnel, an LSR can load-balance traffic over a TE tunnel and an IP path (if the cost for both paths is equal, of course).

Example 8-27 TE Tunnel from Router Berlin to Router Frankfurt berlin#show mpls traffic-eng tunnels tunnel 1

Name: berlin_t1 (Tunnell) Destination: 10.200.254.4

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, type dynamic (Basis for Setup, path weight 2) Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters:

State: dynamic path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -OutLabel : POS0/0, 17 RSVP Signalling Info:

Src 10.200.254.5, Dst 10.200.254.4, Tun_Id 1, Tun_Instance 7 RSVP Path Info:

Explicit Route: 10.200.215.2 10.200.214.1 10.200.254.4 Record Route: NONE

Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info:

Record Route: NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 2 (TE)

Explicit Route: 10.200.215.2 10.200.214.1 10.200.254.4

berlin#show ip route 10.200.254.2 255.255.255.255

Routing entry for 10.200.254.2/32

Known via "ospf 1", distance 110, metric 5, type intra area Last update from 10.200.211.1 on POS0/1, 00:11:14 ago Routing Descriptor Blocks:

* 10.200.211.1, from 10.200.254.2, 00:11:14 ago, via POS0/1

Route metric is 5, traffic share count is 1 directly connected, via Tunnel1

Route metric is 5, traffic share count is 1

Keeping the OSPF cost of the link berlin-brussels at 3, the TE tunnel is fixed over the path berlin-brussels-fankfurt with an explicit path option. The cost of the tunnel is now 4, but the prefixes with this tunnel as next hop still have the IGP cost of 2. Look at Figure 8-25 for the network with the TE tunnel.

Figure 8-25 Tunnel to Router Frankfurt over Router Brussels

Loopback 0 10.200.254.5/32

Loopback 0 10.200.254.6/32

berlin m

TE Tunnel 1 (Cost 4)

brussels

OSPF Cost 1

Loopback 0 10.200.254.3/32

OSPF Cost 1

Loopback 0 10.200.254.4/32

^^ frankfurt

Loopback 0 10.200.254.2/32

paris

To get from berlin to paris, load balancing across the IP path berlin-brussels-paris and the path tunnel 1{berlin-brussels-frankfurt}-brussels-paris still must occur, because none of the IGP costs of the links has changed. However, the traffic going onto tunnel 1 backflows. The traffic on the tunnel arrives at frankfurt and then flows back across the link frankfurt-brussels to the router paris. That means that all the traffic that is sent onto the tunnel toward 10.200.254.2/32 from berlin crosses the link frankfurt-brussels twice. This is surely something you want to try to avoid. Even though the cost of the tunnel is 4, the cost used for the prefixes that have this tunnel as next hop is 2. The reason for this is that the cost or metric for the prefixes using the TE tunnels is calculated from the lowest IGP cost to the tunnel destination. This is true even—as in this case—when the tunnel does not take the lowest IGP cost path to the tail end router. It is this lowest IGP path cost that is used for the prefixes in the routing table that have this tunnel as next hop. Just remember the general rule mentioned in the beginning of this section regarding the cost of the tunnel as used by the IGP. The tunnel and the prefix 10.200.254.2/32 in the routing table of router berlin for Figure 8-25 are shown in Example 8-28.

Example 8-28 Backflow berlin#show mpls traffic-eng tunnels tunnel 1

Name: berlin_t1 (Tunnell) Destination: 10.200.254.4

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 5, type explicit berlin-frankfurt (Basis for Setup, path weight 4) path option 10, type dynamic

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters:

State: explicit path option 5 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -OutLabel : POS0/1, 16 RSVP Signalling Info:

Src 10.200.254.5, Dst 10.200.254.4, Tun_Id 1, Tun_Instance 9 RSVP Path Info:

Explicit Route: 10.200.211.1 10.200.212.2 10.200.254.4 Record Route: NONE

Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info:

Record Route: NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 2 (TE)

Explicit Route: 10.200.215.2 10.200.214.1 10.200.254.4 berlin#show ip route 10.200.254.2 255.255.255.255

Routing entry for 10.200.254.2/32

Known via "ospf 1", distance 110, metric 5, type intra area Last update from 10.200.211.1 on POS0/1, 00:00:56 ago Routing Descriptor Blocks:

* 10.200.211.1, from 10.200.254.2, 00:00:56 ago, via POS0/1 Route metric is 5, traffic share count is 1 directly connected, via Tunnel1

Route metric is 5, traffic share count is 1

Keep the same OSPF cost on the links as before: a cost of 1 on all links and the link berlin-brussels with an OSPF cost of 3. The TE tunnel on router berlin now has the router brussels as destination and is explicitly routed on the path berlin-rome-frankfurt-brussels. Figure 8-26 shows the network with this explicitly routed tunnel.

Figure 8-26 Tunnel to Router Brussels

Loopback 0 10.200.254.5/32

berlin

10.200.215.2

OSPF Cost 1

Loopback 0 10.200.254.3/32

TE Tunnel 1 (Cost 3)

brussels

10.200.212.1

10.200.212.2

OSPF Cost 1

m frankfurt paris

Example 8-29 shows that prefixes on the tail end router or beyond (for example, on router paris) are reachable only through the TE tunnel.

Example 8-29 TE Tunnel from Router Berlin to Router Brussels berlin#show mpls traffic-eng tunnels tunnel 1

Name: berlin_t1 (Tunnell) Destination: 10.200.254.3

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 5, type explicit berlin-frankfurt (Basis for Setup, path weight 3) path option 10, type dynamic

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters:

State: explicit path option 5 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -OutLabel : POS0/0, 17 RSVP Signalling Info:

Src 10.200.254.5, Dst 10.200.254.3, Tun_Id 1, Tun_Instance 13 RSVP Path Info:

Explicit Route: 10.200.215.2 10.200.214.1 10.200.212.1 10.200.254.3 Record Route: NONE

Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info:

Record Route: NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 3 (TE)

Explicit Route: 10.200.211.1 10.200.254.3

berlin#show ip route 10.200.254.3 255.255.255.255

Routing entry for 10.200.254.3/32

Known via "ospf 1", distance 110, metric 4, type intra area Routing Descriptor Blocks: * directly connected, via Tunnel1

Route metric is 4, traffic share count is 1

berlin#show ip route 10.200.254.2 255.255.255.255

Routing entry for 10.200.254.2/32

Known via "ospf 1", distance 110, metric 5, type intra area Routing Descriptor Blocks: * directly connected, via Tunnel1

Route metric is 5, traffic share count is 1

The cost of the shortest IGP path for the TE tunnel is 3. Therefore, the prefixes with the tunnel as next hop also receive a cost of 3, plus the cost of the path from the tail end router to the destination. Notice that both 10.200.254.3/32 and 10.200.254.2/32 have only the tunnel as the next hop. That means the prefixes at the tail end router and the prefixes beyond the tail end router have the tunnel as the only next hop. The reason the prefix 10.200.254.2/32 on router paris does not load-balance over the IP path berlin-brussels-paris and the path tunnel 1{berlin-rome-frankfurt-brussels}-paris—even though the total cost is the same (total cost = 5)—is that the tunnel tail end router crosses the IP path. The CSPF calculation on the head end router notices this and takes the TE tunnel as the only next hop for that prefix.

With autoroute announce, you can change the metric used to calculate what the next hop should be for prefixes. You can change the metric in a direct, relative, or absolute way with the following command:

tunnel mpls traffic-eng autoroute metric { absolute | relative } value

This command allows you to make the TE tunnel more or less preferred as a next hop for the prefixes as compared to other TE tunnels or IP paths. However, you still need to take the restrictions into account that were discussed in the previous section. Setting the value directly with this command does set the cost of the TE tunnel as it is announced to the IGP for all prefixes that are at the tail end router or beyond. Of course, if the prefix is several hops behind the tail end router, you also need to add the cost of that path. This is not so if you change the metric in an absolute way. In that case, all prefixes reachable through the TE tunnel receive that cost, no matter how far beyond the tail end router they might be. The relative keyword lets you change the cost of the tunnel as it is announced to the IGP in a relative way compared to the cost of the lowest cost IGP path. It allows you to adjust the cost from -10 to 10.

NOTE Use this command with caution, because it can cause routing problems if not applied correctly.

Example 8-30 shows adjustment of the announced metric by the TE tunnel. The announced metric is adjusted by decrementing it by 2.

Example 8-30 Adjusting Announced Metric of TE Tunnel berlin#show ip route 10.200.254.3 255.255.255.255

Routing entry for 10.200.254.3/32

Known via "ospf 1", distance 110, metric 4, type intra area Routing Descriptor Blocks:

* directly connected, via Tunnel1

Route metric is 4, traffic share count is 1

berlin#conf t

Enter configuration commands, one per line. End with CNTL/Z. berlin(config)#int tunnel 1

berlin(config-if)#tunnel mpls traffic-eng autoroute metric relative -2

berlin(config-if)#~Z

berlin#show ip route 10.200.254.3 255.255.255.255 Routing entry for 10.200.254.3/32

Known via "ospf 1", distance 110, metric 2, type intra area Routing Descriptor Blocks:

* directly connected, via Tunnel1

Route metric is 2, traffic share count is 1

## Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook