On Thursday, November 14, 2013 07:39:14 PM Jason Lixfeld wrote: > The root cause was due to a fix implemented in 15.3(3)S1a > for CSCtl54835. Essentially, the CLNS mtu is now > properly calculated from the L3 interface MTU whereas > before, the CLNS MTU was always 1497 no matter what the > L3 interface MTU was set to. This fix was not listed in > the list of resolved caveats for that release, but it is > now.
Hmmh, interesting. I've always worked with the impression that the IS-IS MTU is inherited from the interface MTU, both on Cisco and Juniper (although if my ageing photographic memory is anything to go by, a "show clns" might be playing back sights of 1,497 bytes across ports that certainly had a higher physical MTU). There is a special case I've encountered on a Juniper where this is not the case, on some SDH ports on the MX104, i.e., all address families supported on an interface do not inherit the physical interface's MTU, and end up doing their own thing; workaround is to set the MTU at the address family/protocol level. I think this was a bug that is being fixed. Good to hear that Cisco have finally fixed this, although I'm not sure if this is specific to the ME3600X, or whether it affects other IOS-based platforms (might explain a few inconsistent things I've seen with IS-IS MTU, Hello Padding, e.t.c. over the years with IOS systems). Thanks for the tip, Jason. 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/
