On Tuesday 22 June 2010 10:49:34 pm [email protected] 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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
