MPLS TE Bandwidth and Priority

MPLS traffic engineering requires a certain amount of bandwidth available in order for tunnels to be setup. Here we look at an example of what happens when there are too many tunnels and not enough bandwidth.

R2 is connected to R4, R5 and R6 via point-to-point frame relay interfaces. We will create MPLS TE tunnels from these 3 routers to R1.

OSPF, LDP and MPLS traffic-engineering for tunnels have already been enabled globally and on all interfaces.

On serial interfaces we have:
ip rsvp bandwidth 384

On the link between R1 and R2, we have:
ip rsvp bandwidth 1000

Here are our first two tunnels from R5 and R6 to R1:

interface Tunnel1
ip unnumbered Loopback0
tunnel destination 200.0.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric relative -1
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth  350
tunnel mpls traffic-eng path-option 10 dynamic

The tunnels come up fine:

R5#sho mpls traff tun | inc Adm
Admin: up         Oper: up     Path: valid       Signalling: connected

R6#sho mpls traff tun | inc Adm
Admin: up         Oper: up     Path: valid       Signalling: connected

Let’s add a new tunnel on R4 with the same bandwidth. The total bandwidth for all tunnels towards R1 will now be 1050kbps, which exceeds the reservation on R2’s interface. The tunnel will not come up:

R4#sho run int tun 1
Building configuration...

Current configuration : 373 bytes
!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 200.0.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric relative -1
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth  350
tunnel mpls traffic-eng path-option 10 dynamic
end

R4#

The reason the tunnel cannot come up is not very intuitive, “No path to destination”. In this case “path” does not just mean a route, but an actual path that meets the requirements of the tunnel.

R4#sho mpls traffic-eng tunnels tun 1

Name: R4_t1                               (Tunnel1) Destination: 200.0.0.1
Status:
Admin: up         Oper: down   Path: not valid   Signalling: Down
path option 10, type dynamic

Config Parameters:
Bandwidth: 350      kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute:  enabled   LockDown: disabled  Loadshare: 350      bw-based
auto-bw: disabled

Shortest Unconstrained Path Info:
Path Weight: 295 (TE)
Explicit Route: 150.50.24.2 150.50.12.2 150.50.12.1 200.0.0.1
History:
Tunnel:
Time since created: 45 minutes, 4 seconds
Time since path change: 6 minutes, 25 seconds
Prior LSP:
ID: path option 10 [25]
Removal Trigger: tunnel shutdown
Last Error: PCALC:: No path to destination, 200.0.0.1

However with the following command we can see the issue:

2#sho mpls traffic-eng topology 200.0.0.2 | be 12.1
link[3 ]:Nbr IGP Id: 150.50.12.1, nbr_node_id:2, gen:52
frag_id 3, Intf Address:150.50.12.2
TE metric:100, IGP metric:100, attribute_flags:0x0
physical_bw: 1000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)

Global Pool       Sub Pool
Total Allocated   Reservable        Reservable
BW (kbps)         BW (kbps)         BW (kbps)
---------------   -----------       ----------
bw[0]:            0             1000                0
bw[1]:            0             1000                0
bw[2]:            0             1000                0
bw[3]:            0             1000                0
bw[4]:            0             1000                0
bw[5]:            0             1000                0
bw[6]:            0             1000                0
bw[7]:          700              300                0

Here we can verify that indeed there is only 300 kbps still left to allocate to tunnels with priority 7. We can force the tunnel to come up by making the priority better on R4:

R4(config)#int tun 1
R4(config-if)#tunnel mpls traffic-eng priority 5
R4(config-if)#
*Mar  1 03:58:32.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R4(config-if)#

The tunnel came right up! Who was dropped? Let’s take a look at R5, and right away we see this message:

R5#
*Mar  1 03:59:31.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

Priority and bandwidth are two things to keep in mind when you have multiple tunnels in your topology.  Knowing issues like this beforehand can help troubleshoot when tunnels do not come up as expected.

Regards, Bryan (Blog Post by Bryan Bartik)

Tags: MPLE TE Bandwidth, MPLS TE Priority