MPLS TE: Fastreroute issue/question IOS XR

[javiercastro]

I have MPLS TE tunnels configured to protect long distance links between routers in the core of the network. I have primary tunnel UP and also the backup tunnel UP, the problem is that when I try to see if fastreroute is ready it seems that is not there. I have to mention that I haven't configured the autoroute announce command on the primary tunnel (haven't done the traffic migration yet).

The configuration is the following:

interface tunnel-te1

ipv4 unnumbered Loopback0

signalled-bandwidth 5000000

destination x.x.x.x

fast-reroute

path-option 1 explicit name primary

!

interface tunnel-te2

ipv4 unnumbered Loopback0

backup-bw 4000000

destination x.x.x.x

path-option 1 explicit name backup

!

mpls traffic-eng

interface TenGigE0/1/0/0

backup-path tunnel-te 2

!

interface TenGigE0/2/0/0

!

Every thing else is already configured (rsvp, osfp-mpls-te)

The output of the show commands are:

RP/0/9/CPU0:router#show mpls traffic-eng fast-reroute database summary

Status Count

---------- ----------

Active 0

Ready 0

Partial 0

RP/0/9/CPU0:router#show mpls traffic-eng tunnels backup

tunnel-te2

Admin: up, Oper: up

Src: y.y.y.y, Dest: x.x.x.x, Instance: 222

Fast Reroute Backup Provided:

Protected LSPs: 0

Backup BW: any-class; limit: 4000000 kbps, Inuse: 0 kbps

Protected i/fs: TenGigE0/1/0/0

Is there anything I should be worried about? is this a normal behaviour knowing that the autoroute command is not configured yet?

Many thanks for your help.

[Harold Ritter]

Javier,

Is the primary LSP going through TenGigE0/1/0/0?

Regards

[javiercastro]

Yes, that is correct.

[javiercastro]

As you can see in the "show mpls traffic-eng tunnels" output it says that fastreroute is enabled, but I can not see it in the fastreroute database.

RP/0/9/CPU0:P-MTY01#sh mpls traffic-eng tunnels 1

Name: tunnel-te1 Destination: x.x.x.x

Status:

Admin: up Oper: up Path: valid Signalling: connected

path option 1, type explicit primary (Basis for Setup, path weight 10000)

G-PID: 0x0800 (derived from egress interface properties)

Config Parameters:

Bandwidth: 5000000 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff

Metric Type: TE (default)

AutoRoute: disabled LockDown: disabled Policy class: not set

Loadshare: 0 equal loadshares

Auto-bw: disabled(0/0) 0 Bandwidth Requested: 5000000

Direction: unidirectional

Endpoint switching capability: unknown, encoding type: unassigned

Transit switching capability: unknown, encoding type: unassigned

Fast Reroute: Enabled, Protection Desired: Any

History:

Tunnel has been up for: 00:49:17

Current LSP:

Uptime: 00:49:17

Prior LSP:

ID: path option 1 [435]

Removal Trigger: path verification failed

Path info (OSPF 1000 area 0):

Hop0: y.y.y.y

Hop1: z.z.z.z

Do you think this is an issue I should be worried about?

[Harold Ritter]

Javier,

Can you provide a "show mpls traffic-eng tu xx detail" for both tunnel 1 and 2.

Regards

[javiercastro]

I already found the issue. On the backup tunnel the back-bw value was lower than the signalled-bandwidth in the primary tunnel.

Many thanks.