Hi Atif,

hamalawy1 · ‎09-22-2010

hi everyone,

i'm doing this lab with 1 tunnel with 2 path-options specified explicitly... the problem is when the first path is down, the second comes up.. but when the first comes up again.. the second path remains active.. how can i fix this?.. here's some data for you

R1

=========

mpls traffic-eng tunnels

mpls traffic-eng link-management timers periodic-flooding 30

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip ospf 1 area 0

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 7.7.7.7

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth 2000

tunnel mpls traffic-eng path-option 1 explicit name R1-R2-R3-R4-R5-R6-R7

tunnel mpls traffic-eng path-option 2 explicit name R1-R2-R3-R4-R6-R7

tunnel mpls traffic-eng record-route

no routing dynamic

!

interface FastEthernet0/0

ip address 10.1.2.1 255.255.255.252

ip ospf 1 area 0

speed 100

full-duplex

mpls ip

mpls traffic-eng tunnels

ip rsvp bandwidth 5000

!

interface FastEthernet0/1

no ip address

shutdown

speed 100

full-duplex

mpls traffic-eng tunnels

ip rsvp bandwidth 5000

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

!

ip forward-protocol nd

!

ip http server

no ip http secure-server

!

ip explicit-path name R1-R2-R3-R4-R5-R6-R7 enable

next-address 10.1.2.2

next-address 10.2.3.2

next-address 10.3.4.2

next-address 10.4.5.2

next-address 10.5.6.2

next-address 10.6.7.2

next-address 7.7.7.7

!

ip explicit-path name R1-R2-R3-R4-R6-R7 enable

next-address 10.1.2.2

next-address 10.2.3.2

next-address 10.3.4.2

next-address 10.4.6.2

next-address 10.6.7.2

next-address 7.7.7.7

!

mpls ldp router-id Loopback0 force

==================================================

R1#sh mpls traffic-eng tunnels

Name: R1_t0 (Tunnel0) Destination: 7.7.7.7

Status:

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

path option 1, type explicit R1-R2-R3-R4-R5-R6-R7 (Basis for Setup, path weight 6)

path option 2, type explicit R1-R2-R3-R4-R6-R7

Config Parameters:

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

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 2000 bw-based

auto-bw: disabled

InLabel : -

OutLabel : FastEthernet0/0, 28

RSVP Signalling Info:

Src 1.1.1.1, Dst 7.7.7.7, Tun_Id 0, Tun_Instance 27

RSVP Path Info:

My Address: 10.1.2.1

Explicit Route: 10.1.2.2 10.2.3.1 10.2.3.2 10.3.4.1

10.3.4.2 10.4.5.1 10.4.5.2 10.5.6.1

10.5.6.2 10.6.7.1 10.6.7.2 7.7.7.7

Record Route:

Tspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

RSVP Resv Info:

Record Route: 10.1.2.2 10.2.3.2 10.3.4.2 10.4.5.2

10.5.6.2 10.6.7.2

Fspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

History:

Tunnel:

Time since created: 19 minutes, 22 seconds

Time since path change: 36 seconds

Current LSP:

Uptime: 36 seconds

Selection: reoptimation

Prior LSP:

ID: path option 2 [26]

Removal Trigger: path error

LSP Tunnel R7_t0 is signalled, connection is up

InLabel : FastEthernet0/0, implicit-null

OutLabel : -

RSVP Signalling Info:

Src 7.7.7.7, Dst 1.1.1.1, Tun_Id 0, Tun_Instance 41

RSVP Path Info:

My Address: 1.1.1.1

Explicit Route: NONE

Record Route: 10.1.2.2 10.2.3.2 10.3.4.2 10.4.5.2

10.5.6.2 10.6.7.2

Tspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

RSVP Resv Info:

Record Route:

Fspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

===========================================================

THEN WHEN THE LINK FROM R4 TO R6 DIES

R1#sh mpls traffic-eng tunnels

Name: R1_t0 (Tunnel0) Destination: 7.7.7.7

Status:

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

path option 2, type explicit R1-R2-R3-R4-R6-R7 (Basis for Setup, path weight 5)

path option 1, type explicit R1-R2-R3-R4-R5-R6-R7

Config Parameters:

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

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 2000 bw-based

auto-bw: disabled

InLabel : -

OutLabel : FastEthernet0/0, 28

RSVP Signalling Info:

Src 1.1.1.1, Dst 7.7.7.7, Tun_Id 0, Tun_Instance 29

RSVP Path Info:

My Address: 10.1.2.1

Explicit Route: 10.1.2.2 10.2.3.1 10.2.3.2 10.3.4.1

10.3.4.2 10.4.6.1 10.4.6.2 10.6.7.1

10.6.7.2 7.7.7.7

Record Route:

Tspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

RSVP Resv Info:

Record Route: 10.1.2.2 10.2.3.2 10.3.4.2 10.4.6.2

10.6.7.2

Fspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

History:

Tunnel:

Time since created: 19 minutes, 56 seconds

Time since path change: 3 seconds

Current LSP:

Uptime: 3 seconds

Selection: reoptimation

Prior LSP:

ID: path option 1 [27]

Removal Trigger: path error

Last Error: PCALC:: Can't use link 10.4.5.1 on node 4.4.4.4

==================================================

WHEN THE LINK BETWEEN R4 TO R6 IS UP AGAIN.. REMAINS THE SAME

any ideas.. sorry but my battery died when i was posting this... hope this gives you a complete overview..

Atif Awan · ‎09-22-2010

hamalawy1 wrote:
hi everyone,
i'm doing this lab where i has 1 tunnel with 2 path-options specified explicitly... the problem is when the first path is down, the second comes up.. but when the first comes up again.. the second path remains active.. how can i fix this?.. here's some data for you
R1
=========

Is your first path 'better' than the second path (think from a CSPF perspective). If yes then with default settings you will need to wait for the periodic reoptimization timer to kickin before the tunnel reoptimizes to the best path. Default setting is 3600 seconds if I recall correctly.

Atif

hamalawy1 · ‎09-23-2010

yes, i tried changing the timer to 30 sec but no use.. but you are correct from the CSPF prespective, it's indeed not better than the other pass, but the point is this is labeled as OPTION 1 and the other is OPTION 2 ... isn't option 1 supposed to have some priority over the latter one? i posted the configuration and some show commands.. maybe you can help

thank you again atif

Atif Awan · ‎09-23-2010

hamalawy1 wrote:

yes, i tried changing the timer to 30 sec but no use.. but you are correct from the CSPF prespective, it's indeed not better than the other pass, but the point is this is labeled as OPTION 1 and the other is OPTION 2 ... isn't option 1 supposed to have some priority over the latter one? i posted the configuration and some show commands.. maybe you can help

thank you again atif

Reoptimzation will happen in case a better path is found. If there is no better path then the current path will continue to be used.

When a tunnel is being initially setup the path options are tried sequentially so in this case your Option-1 will be tried first and if it is valid it will be used. However, once a tunnel is setup via Option-2 (Option-1 was invalid) it will move back to Option-1 in case it is a better path. If it is not then the tunnel will not reoptimize.

Atif

GIANRICO FICHERA · ‎06-22-2017

Hi Atif,

Sorry my late to reply, possibly many things have changed. In any case, I have a tunnel between an ASR900 and ASR9000 and if the primary path goes down it will be picked again when restored even if not optimal. I saw that in every re-optimization the system tries always the path options sequentially.

interface Tunnel1001
 description --- Tunnel1001: test ---
 ip unnumbered Loopback1
 load-interval 30
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination 192.168.118.129
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 10 explicit name tunnel1001.p0   <--- worst one
 tunnel mpls traffic-eng path-option 20 dynamic     <--- better one
!

If the explicit-path tunnel1001.p0 fail the system goes to the dynamic option. When I fix the explicit path this happen:

Jun 22 19:49:00.411:     192.168.118.129: 192.168.118.129
Jun 22 19:49:00.411: TE-PCALC-API: 192.168.201.1_1281->192.168.118.129_1001 {7}: P2P LSP Path Lookup result: success
Jun 22 19:49:00.411: TE-REOPT-HE: Tunnel1001 [1281]->192.168.118.129 new path: option 10 [1281], weight 125
Jun 22 19:49:00.411: TE-REOPT-HE: Tunnel1001 [1281]->192.168.118.129 old path: option 20 [1214], weight 3
Jun 22 19:49:00.411: TE-REOPT-HE: Tunnel1001 [1281]: set as reopt
Jun 22 19:49:00.515: TE-REOPT-HE: Tunnel1001 [1281] delay install 3 sec

As you can see the new path has weight 125 but it becomes the active one.

Thankyou, Gianrico Fichera

hbruyere · ‎10-29-2010

Did you give a try with this?

---

int tunnel0

tunnel mpls traffic-eng path-option 1 explicit name

 tunnel mpls traffic-eng path-option protect 1 explicit name

---

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_path_prot.html

Herve

Ps: did not notice I was resurrecting a old tread

Mahesh Gohil · ‎10-29-2010

Hi,

In addition to what atif said...

Path protection option we are using for keeping resource ready incase primary fails. it is quite same as using different path-option ..and the only difference is path protection has better convergence than igp convergence because it is presignalled LSP path.

Normally we configure path-option for explicit path and leave last statement as a dynamic path as a backup of all path-option.

We have preempt facility but it is between tunnels and not between different path-option.

We configure path-option for explicit path because it is explicit and it could be possible that the next-address specified in explicit path is not reachable or you want to do some activity on mentioned path so as a backup it will be rerouted to next path-option.

If you want your traffic always prefer first path option as and when available you need to create
two tunnels and you can put some priority so at time of reoptimization it will preempt to first one only

Hope this is useful

Regards

MPLS TE , path-option not switching automatically