MPLS/OSPF Fasthellos

Unanswered Question
Jun 23rd, 2010

I am setting up an MPLS VPN network.

Customer needs fast convergenace.

So I thought backbone IGP(OSPF) could be configured with fast hellos for the same. At the time of a backbone link failure, even if OSPF converges fast customer is experiencing an outage of 20 seconds between the CPEs(normal ping). I think the longer switchover delay may be due to LDP convergence. Can someone help me with this.

Any idea of reducing LDP convergence time.

I am using 4948 switches.

Thanks in advance


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Olivier ARRIGHI Wed, 06/23/2010 - 12:47

Hi aneesh

Not sure to understand well your topology. Do you have some mpls enable between the PE and CE? The link failure you are talking about is a failure between the PE and CE?

Is the link between PE and CE directly connected?If yes, did you try BFD for link failure between PE and CE? This would avoid using OSPF for Fast Hello convergence.(You might want to tune OSPF throttle and pacing timers though)

If you talk about backbone failure, BFD could help also if you don't have directly connected links. You might also consider traffic engineering with Fast reroute, TE path protection could also be an option.

have fun


aneesh.ts Wed, 06/23/2010 - 13:29

Hi olivier,

thanks for the reply mate.

I am running BGP as PE-CE protocol.

The link i was talking about is my backbone link.

OSPF is used as IGP. BGP obviously us used for MPLS VPN.


inderdeeps Wed, 06/23/2010 - 20:39

Hello Anish,

Greetings of the day,

Well MPLS VPN Convergence Times Depending on the PE-CE Protocol. We have different protocols having the following convergence time as below:

Static: 25 seconds

OSPF: 35 seconds

BGP:   85 seconds

EIGRP:25 Seconds

RIPV2 :85 seconds

Option 1:

You can use static routing in between PE-CE as there is a 60 sec convergence difference between static and BGP routing protocols.

Option 2:

Tuning the BGP

The main delay in route convergence with the BGP protocol is the time taken to advertise a new or deleted VPN route. This time is primarily driven by the advertisement interval timer. This is set by default to 5 seconds for internal BGP (convergence point T4) and 30 seconds for external BGP (convergence points T1 and T7).

you can chose to reduce the internal BGP timer to 1 second and the external BGP timer to 5 seconds. These new timer values allow routes to be distributed across the backbone network more quickly. They also provide a small delay for the advertisement of these routes to external peers to allow a certain amount of packing of routes into the updates.

Using these new timer values, you can able to drop the theoretical maximum convergence time (when BGP-4 is used on the PE-CE links) to 27 seconds. (This is the default theoretical maximum of 85 seconds minus twice a 4-second saving for internal BGP and twice a 25-second saving for external BGP.) This time is more inline with the other routing protocols.

Option 3:

hello state timer:RSVP hellos can be used to detect when a neighboring node is down. The hello state timer then triggers a state timeout. As a result, network convergence time is reduced, and nodes can forward traffic on alternate paths or assist in stateful switchover (SSO) operation.

Or you can use BFD for link failure between PE and CE



chintan-shah Wed, 06/23/2010 - 23:48


Since you are looking for fast convergance for backbone link failure assuming PE-P link failure.

There are couple of stuff you can do based on avilability of feature in your box.

   BFD is obviously good choice but be sure about timers as there could be false failure detection if timers are very aggresive and BFD being processed on RP CPU.

So What is your P and PE device ? it would be easy to implement BFD as BFD gets process on 12K on LC than RP.

How many VPNV4 routes you have as on today on PE because update of RIB/FIB takes time per prefix in case of link failure due to flat BGP table in IOS.




This Discussion