On Sunday 18 January 2009 01:57:45 pm Justin Shore wrote: > I may do a feature diff against > SRC though to see if it's doable.
If you do decide to try SRC, recommend SRC3 as a minimum. Earlier releases are very buggy, and we've seen random system reboots with BFD enabled, which was the worst for us. > Is there a particular name for the feature? From what I can tell at: http://www.cisco.com/en/US/docs/ios/12_2sr/12_2src/12_2_33_src_newfeatlist.html the feature name should be "Per Subinterface MTU for Ethernet over MPLS (EoMPLS)"; but it doesn't seem to show up in FN. At any rate, you can describe what you need to your account team and let them know it's currently coded in SRC. > Since you're > an IS-IS guru... Hardly :-). > I'll throw a question your way. I removed > 3 sub-ints and added their clones on the other physical > interface. The 3 routes associated with the sub-ints > were not pushed upstream into the core. I had connected > routes on the 7201 but they weren't being propagated on > even though 'sh ip route' said they were being redisted. > I'm redistributing connected in IS-IS. Previously the > ints had no IS-IS config on them. To get those 3 routes > pushed into my IGP I had to enable IS-IS on each sub-int > with 'ip router isis'. I've seen this flaky behavior > before but usually just add IS-IS to the interface and > forget it. Any idea what causes this to happen or how to > avoid the problem? I've heard of similar issues regarding redistribution of Connected routes between IS-IS and EIGRP, as well as between IS-IS and OSPF (both cases being a feature, not a bug), but not from the Connected RIB into IS-IS. Suffice it to say, my redistribution experience with IS-IS has been static routes and between levels (route leaking), and both have worked with no problems. I wouldn't foresee any issues redistributing Connected routes, as long as you push them into the right IS-IS level. Your issue sounds like a bug (especially since you say it worked prior to your sub-interface migration) - I'd report it to TAC for some feedback. But as Pelle has mentioned, I'd recommend setting the customer sub-interfaces as 'passive'. Not only do you benefit from injecting the interface prefix into the core, but you also avoid having to run IS-IS on the interface itself, preventing the unnecessary generation of LSP's and Hello's, thus, keeping your IGP lean. Imagine if your customer base on this router grew, and you had to enable IS- IS on each sub-interface :-). Further, this shields you from any nasties, should your customers turn up IS-IS on their interface toward your router and "potentially" become a part of your network. Ultimately, when you have the time, consider using IS-IS just for your infrastructure and Loopback addresses, and use iBGP for your customer interface + assigned prefixes. > I've seen a number of flaky IS-IS > things happen. My favorite is when one router decides to > send 8996 byte IIHs and the other side drops them as > being too big. Did both sides have the same MTU value? If so, I'd disable Hello Padding ('no hello padding' under 'router isis x'). Adjacencies would still form since IOS will pad the first five (5) Hello frames to the full MTU size, in order to detect MTU mismatches. Subsequent Hellos would not be padded. Suffice it to say, IS-IS on SRC has been stable for us, except for CSCsu67637 (IPv6 address for passive interface not in ISIS database). But as mentioned, if you choose to, don't look at anything else besides SRC3. Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/