Routing

This is a pretty simple scenario:

R1--------------- R2

|                            |

|                            |

+-------R3----------+

R1 and R2 are directly connected, one-hop MPLS LSP established between the 2 routers. The primary path is a one-hop path and the secondary path is a de-tour path via R3.

Every time when I put the link between R1 and R2 down, the LSP path will be swing to the secondary path. Then I brought the link back, then it will take quite a while (usually tens of seconds) for R1 to mark the original primary path to be "up":

For example:

===========

The interface was up at 10:54:12:
Apr 22 10:54:12 m120-b-re0 mib2d[1571]: SNMP_TRAP_LINK_UP: ifIndex 628, ifAdminStatus up(1), ifOperStatus up(1), ifName so-5/0/1.0

But the primary path was up at 10:54:46:

18 Apr 22 10:54:46.701 Selected as active path
17 Apr 22 10:54:46.699 Record Route: 1.2.3.4(flag=0x20) 10.0.0.1(Label=3)
16 Apr 22 10:54:46.699 Up

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

Here is my MPLS configuration:

lab@m120-b-re0> show configuration protocols mpls
inactive: traceoptions {
  file mpls-trace_2 size 10m files 10;
  flag error;
}
no-propagate-ttl;
ipv6-tunneling;
label-switched-path NDLTT-ER1-to-CHENTT-ER2 {
  traceoptions {
    file mpls size 10m files 10;
    flag all;
  }
  to 202.163.59.107;
  ldp-tunneling;
  retry-timer 5;
  revert-timer 5;
  no-cspf;
  link-protection;
  primary to-R2-direct;
  secondary to-R2-via-R3;
}
path to-R2-direct {
10.0.0.2 strict;
}
path to-R2-via-R3 {
  10.1.0.2 strict;
  10.2.0.2 strict;
}
interface all;
interface fxp0.0 {
  disable;
}

I knew that the signaling for establish the primary path back would take time, but for a one-hop path with static strict next-hop configured, 30+ seconds could be a little bit longer than expected?

Hello,

Are You using OSPF? Are You using p2p interfaces in OSPF?

If the answer is Yes+No then there is default 40sec(==default Dead interval) OSPF "Wait" period after ge-* interface comes Up/Up.

HTH

Thanks

Alex

Hi Alexander:

The interface is sonet so they should be point-to-point already I guess...

According to configuration above link-protection enabled a long with a secondary LSP. so let breakdown what will be happen when the a failure occurs on the direct link between R1-R2

1- Primary path will be re-routed over the links through R3 using the pre-established link protection bypass LSP

2- PLR (Point of local repair) will signal a Path Error message to the ingress LSR ( which is in our case is the same router) . highlighting that the LSP is temprorarly repaired over R3 path and the headend should find another path if applicable .

3- Since the Head-end (R1) configured with a secondary path , this will lead to establish the second LSP , re-route the traffic over it then tear the primary path down.

4- When the primary path became available again, it will wait for 5 seconds before retrying to establish the connection through the primary path again ( i.e. retry-timer configured to 5 and default is 30secs). after establishing the primary LSP it will wait for more 5 seconds before reverting the traffic back to the primary LSP ( since the revert-time set to 5) .

Conclusion:

=========

- According to configuration above,  after the primary path became available router will take at least 10sec to switch the traffic back to the primary LSP ( retry-timer + revert-timer = 5+5 = 10 seconds).

- According to above topology you can sustain with a primary LSP enabled for link protection only with no need for a secondary LSP and hence whenever the primary Path is available again the traffic will be switched back to it in a msecs.

So, try to deactivate the secondary LSP and then try again.

Regards,

Karim Ayoub