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

Justin Shore justin at justinshore.com
Sun Jan 18 00:57:45 EST 2009


Mark Tinka wrote:
> You can set the 'xconnect' MTU independently on the sub-
> interface, but you'll need SRC for that:
> 
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_any_transport_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1047362

I don't actually run SR code on any of our 7200s.  I run 12.4T.  I know 
everyone has their favorites and particular reasons for one over 
another.  In my experience 12.4T has been relatively stable (once you 
get at least a T1 release out for a given (#) release).  Our 7200s are 
particularly fancy, even the ones terminating OC3s of DSL customers.  I 
may do a feature diff against SRC though to see if it's doable.

Is there a particular name for the feature?  I can bug our account team 
to press for it to be included in 12.4T.  That would be an extremely 
helpful feature the more I think about it.

> Some vendors do allow you to ignore MTU mismatch. Whether 
> that's a good or bad thing is an operational matter for your 
> network. We prefer to have them similar.

This could be useful but you're right.  It would probably be best if it 
matched on both sides.  It would be handy if there was a solution for 
working around a mismatch though, even if it isn't recommended best 
practice.

> That's what we do, in the case of edge routers.
> 
> We'd, at least, use an edge router that has three (3) 
> interfaces - 2x facing upstream to the core, 1x as the 
> 802.1Q trunk to customers (more for customer redundancy, 
> e.t.c.).

I went ahead and rigged up a second link between the 7201 and 4948.  I 
moved all infrastructure sub-ints to the new link and left the customer 
sub-ints alone.  I set up the infrastructure link with a MTU of 9000 and 
the customer link at the default of 1500.

I did run into one problem during the swap.  Since you're an IS-IS guru 
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 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.  Fixing 
that usually requires removing all IS-IS config and reapplying it or 
rebooting.  When it works though it's usually very solid.

Thanks
  Justin




More information about the cisco-nsp mailing list