[c-nsp] EoMPLS from ME3750 to 7201 GigE sub-int

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090118/b3d3ba6d/attachment.bin>