[c-nsp] ISIS MTU Ignoration good/bad???

[Adam Vitkovsky]

Yes please that is the behavior I would expect to remain in place, otherwise could be disabled by a knob if needed. 

 

 

adam

From: Matthew Walster [mailto:matthew at walster.org] 
Sent: Thursday, June 27, 2013 12:37 PM
To: Adam Vitkovsky
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ISIS MTU Ignoration good/bad???

 

On 26 June 2013 16:07, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:

Hi folks,
I have just recently noticed that newer ISIS implementations actually ignore
interface MTU discrepancies.
I was relying on the local interface MTU comparison against the IIHs size to
discover any MTU inconsistencies.
I believe there should be a knob to enable/disable MTU comparison same as
there's currently a knob to turn on/partially-off/off(XR) the IIH padding.
I'd like to know the opinion of the community on this matter please.

 

AIUI, IS-IS does not insist on MTUs being identical on either side of the link. It was only OSPF that screwed this up.

 

What I think you're mentioning is that Cisco did hello-padding so that an IS-IS frame (once received) could only be processed if it met the buffer size on both sides -- it's documented here:

 

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00801e1e2b.shtml

 

M