Comment on MPLS TE Design

[limtohsoon]

Hi Sir,

Attached is the network diagram of a simple MPLS VPN network. There are 6 P/PE routers located at 3 different sites. The sites are linked with dark fiber via DWDMs. At each site, there are 2 P/PE routers (e.g. PE11 & PE12, PE21 & PE22, PE31 & PE32) connected back-to-back with MMF fiber.

At each site, customer services usually dual-home to both PE routers.

The diagram shows the TE and FRR design. Also attached is TE configlet of PE12 and PE21. I'm deploying only link protection. Can you please comment on the drawback/disadvantages of this design and recommend better alternatives?

Thank you.

B.Rgds,

Lim TS

[swaroop.potdar]

1) Based on your physical topology, Link protection is the only viable method which you can adopt for protection.

2) Based on your recovery requirement, ( i believe you are trying to achieve sub 50ms healing) this would directly be dependent on the number of LSP's you are protecting using these TE tunnels.

3) And also the healing time would be directly proportional to the carrier delay for GEth intf to delcare it down.

4) You need to be careful about the bandwidth consumption on your network, upon backup trigger the other links should have enough bandwidth (this is applicable for traffic after normal IGP convergence also)

Recommendation:

a) looking at your topology why dont you consider BFD with OSPF for fast convergence, if the number of LSP's you are protecting on a path is too high.

b) If you are planning to implement TE then use aggressive RSVP hello parameters for faster converegence, rather than just replying on the Intf down status.

c) In your config you dont need dynamic and explicit path options for Primary, Explict only suffices.

HTH-Cheers,

Swaroop

[limtohsoon]

Hi Swaroop,

Thanks for your response. Yes, I'm trying to achieve sub-50ms healing.

Each customer routes are advertised by their respective pair of P/PE routers. The BGP and VRF are configured such that PE load-balancing is possible to any customer routes. The traffic pattern indicates that each PE is very likely need to forward traffic to all other PEs.

I've configured the following fine-tuning:

(1) BFD over OSPF is enabled on all core GigE interfaces.

(2) OSPF SPF and LSA throttling are enabled. OSPF hello and dead intervals are set to lower values.

(3) BGP graceful restart is enabled. Peer groups are used on all PE routers and RRs.

Your statement "use aggresive RSVP hello parameters", are you referring to MPLS TE-RSVP Hello State Timer? See URL below:

http://www.cisco.com/en/US/partner/products/ps6922/products_feature_guide09186a008027dbda.html

Did you see any issue in my TE design to meet the above network requirements? Do I require to build TE tunnels from a PE to all other PE routers? Is link protection required for the local back-to-back links between the PE routers?

Thank you.

B.Rgds,

Lim TS

[swaroop.potdar · Accepted solution]

As replied earlier, looking at your topology, and the protection requirement ( for all core links) this is the only way you can enable protection. So the way you have done the TE config for your rquirementsm its correct and i dont see any problem with that.

On the corollary I want you to consider these points and discuss internally, and take the right decision.

1) How will customers who are connected to PE11 who want to go to PE21 be FRR'd. As the backup mechanism is there only for customers on PE12. ( the same applies to all other pops)

2) Now look at the whole thing practically, FRR can do protection, but that should not be the only reason to deploy it, as with MPLS TE, come lot of admistrative overheads, its not the kind deploy once and forget.

3) Also you will surely run out of bandwdith of just 1 GiG between pops, and since there has to be protection also, you can exceed beyond max 500MB between pops. So after some time you may need to provision secondary links between all pops. So going by this reasoning it is always suggested to have dual links between pops and load share over them.

Overall, the strategy of FRR for protection in this topology should be rethought about with long term perspective, rather than short term benefits which will come with administrative overheads and maintenance problems.

HTH-Cheers,

Swaroop

PS: on the theoritical side

Q//

"Do I require to build TE tunnels from a PE to all other PE routers? Is link protection required for the local back-to-back links between the PE routers? "

//A

Yes you will need to have Primary Tunnels from all PE to other PE where you are trying to protect.

Although Backup tunnel would be One per link.

//Q

are you referring to MPLS TE-RSVP Hello State Timer?

//A

Yes.

//Q

BGP graceful restart is enabled. Peer groups are used on all PE routers and RRs

//A BGP graceful restart has got nothing to do with FRR. Although you need to enable SSO for your SUP, NSF for IGP, GR for LDP and also GR for BGP to have HA for your VPN customer.

//Q

BFD over OSPF is enabled on all core GigE interfaces.

(2) OSPF SPF and LSA throttling are enabled. OSPF hello and dead intervals are set to lower values

//A

The above parameters also dont play any role in FRR. Although they help for faster convergence, they can also be used independently for Fast Healover Times in absence of MPLS TE and FRR. (as such there is no comparision)

HTH-Cheers,

Swaroop

Also close these two previous threads, opened by you.

MPLS TE over EtherChannel links Oct 8, 2006.

Is auto-bw recommended in MPLS TE environment? Oct 8, 2006

[swaroop.potdar · Accepted solution]

Have replied to your query,

If you have any further queries feel free to put them across, or if you are ok with it you can close the thread.

HTH-Cheers,

Swaroop

[pmaffei]

Any tests/comments on

MPLS TE-RSVP Hello State Timer ??

in terms of router performance.

If I set the refresh timer to 1 sec in 5 interfaces?

[swaroop.potdar]

In a test enviornment if you set the RSVP refresh to 1 sec on 5 interfaces shouldnt have much of a performance impact.

But it may make a difference under real load conditions, where you links may be congested or resources may be loaded to the full.

Its more a question of product performance, so to get a reliable base or trend line you should check with your local Cisco SE.

HTH-Cheers,

Swaroop