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
_______________________________________________
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/
