[c-nsp] MPLS best practices question

[Mark Tinka]

On Tuesday 22 June 2010 10:49:34 pm 
cisconsp at secureobscure.com wrote:

> 1)       IGP LDP Sync. I am really looking for some
>  direction as to where it makes sense or not to use. The
>  same is also true for the IGP LDP startup delay timers.

We don't use it - we instead use IETF Graceful Restart for 
LDP and IS-IS.

> 2)       OSPF timers or BFD? Currently my approach has
>  been ospf timers of 1/4, its fast and seems pretty
>  compatible with everything I have tried it on. All of my
>  links are direct between routed ports so there are no
>  intermediate devices that would keep a link lit after
>  equipment failure. I know BFD makes sense but some of my
>  code is old and linecards are flakey so I'm curious to
>  know who has ditched low timers for BFD or vice versa.

We run BFD for IS-IS.

It's unstable on the NPE-G1, but works great on the NPE-G2, 
but can have false negatives when CPU utilization goes up 
(software routers).

We've seen more stable performance of BFD on hardware-based 
platforms (of course).

> 3)       OSPF costing, automatic bandwidth-based or
>  manual costing of PE-P and P-P links? I have seen both
>  used in production before, I do have 10gig interfaces
>  and 40gig port-channels so I would need to alter the
>  ospf reference bandwidth if auto-costing.

We do manual costing of the IGP, with a self-imposed 
reference bandwidth of 1Tbps.

> 4)       MTU on p2p gigabit ethernet links. Currently I
>  have stolen another list members MTU settings using 1530
>  for global & mpls MTU, and 1524 as IP MTU on all PE-P
>  and P-P interfaces. I don't have any jumbo frame
>  requirements, but do have upstream providers that may
>  not support jumbo so I'm trying to keep the MTU fairly
>  low.

We run 9,000 bytes on all core links.

We run 1,500 bytes on peering links.

Advice here would be to run with the worst MTU value in your 
network.

> 5)       Other knobs and tweeks? I'm usually a
>  minimalist, I go forward with the default settings and
>  test, then alter as little as I need to meet any special
>  needs. With that in mind, I do expect to find things
>  that are necessary to modify but really would like to
>  see wide adoption or clear requirements in doing so.

Same.

It is not uncommon to find that long-and-winded ways we've 
implemented features have now been made possible by a single 
command. In such scenarios, consider making your life easier 
after testing the command still achieves the same goal.

There's a lot of knobs in the IGP's, and in most cases, you 
don't need tons of them. Generally, if you're not sure 
whether a feature helps you, you probably don't need it.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100623/34ec10e3/attachment.bin>