Thanks for chiming in - I was hoping you would...
That's why you threw the softballs. ;-)
Thanks for the clarification on the LSP size. Is this a value based on the
work done to increase the maximum LSP size by creating zero-cost adjacencies
to virtual ISs in the sending IS? I was basing my statement on the
1142/1195 specs, where the PDU Length field is 16 bits.
There are a number of implementation hacks that could be done, though the
virtual IS hack is an obvious one. Without any hacks, you get 256*1492
bytes of LSP space for the router, plus that much for each pseudonode.
Note that each "fragment" is a separate PDU, so the 16 bits applies to each
by itself. (The choice of the term "fragment" is unfortunate as it carries
much baggage from IP; perhaps a better term is "hunk" or something. Think
of it as equivalent to a pile of OSPF LSAs or something.)
> This is mostly deprecated due to operational problems in the field.
> The Juniper implementation pads LAN IIHs to the maximum LSP size
> (1492), which is the only thing that the protocol mechanism is
> attempting to ensure. I vaguely recall making the same change in the
> cisco implementation years back, but my memory is hazy.
It has been changed back! Mike Shand may know the reason. I saw this
yesterday where an adjacency would not form over an ATM subinterface that
had mismatched MTUs.
Could well be, or else it was never changed, and we just yelled at
people who were bridging dissimilar media to "just say no." The
original intent (Mike was there, so he should know) was to ensure that
LSPs would flood everywhere, so everything had to be able to carry
1492 bytes; by padding Hellos to 1492 bytes you could in theory detect
the media incapable of doing the job. As an MTU mismatch detection
mechanism, however, it does a lousy job, because it is far too
indirect in its approach, and (unless you read too much into the spec,
as some implementors have done) ISIS is supposed to ignore how much
padding is present in the received packets, so it is only effective if
the receiving interface drops the packet for being too large. For
real MTU detection it would be trivial to throw an extra option into
the IIH and define direct procedures to deal with it.
> You cannot adjust the LSP size in the Juniper implementation; it is an
> architectural constant in the protocol. There are proposals afoot to
> make this settable so that ISIS can run over somewhat arcane media
> with miniscule MTUs, but so far we have not seen any request for it.
Like the DCN? ;)
I think that qualifies as "somewhat arcane."
This is more of a problem on Cisco's, which as you know set DS3, HSSI, and
higher-speed media to an MTU of 4470, where as the T1s and V.35 type serials
and fast serials are still at 1500.
This should *not* be a problem at all if the media can all support >= 1492
bytes. Thus the Junos hack.
This is what threw me. I know 10589 specifies a recommended maximum LSP
size of 1492. And all of my routers don't have enough TLV info to create an
LSP greater than 1492, but I wasn't sure. As an aside, I thought that the
LSP-MTU value was put there to interoperate with SONET gear, for which the
DCC specifies and MTU of 512 or 576, I can't remember. I remember the NLSP
hack, but I had always assumed it was done after the CLNS piece.
1492 isn't recommended, it's required (the SONET stuff
notwithstanding; weakening the requirement for SONET is in progress.)
It was fixed in the original IOS ISIS code, but became variable when
NLSP was written, which as a side effect became an ISIS rewrite, which
by accident of history became the IGP of choice in large ISPs. But
that's another story.
So, just for clarification and my own piece of mind (as this thread was
making me rethink my GigE deployments where POS links exist as well:)
1) JUNOS does not PAD IIHs.
It pads to 1492 bytes.
2) MaxLSPFragmentSize is 1492, regardless of connected media MTU.
3) MaxLSPSize is 381KB
ISIS doesn't have a concept of an LSP separate from a fragment; a "fragment"
in ISIS terms *is* an LSP. Thus there isn't anything that is defined as
381KB. (You are free to use "fragment" numbers 0 and 255 as your only
LSPs, for example, and it is perfectly legal. Only fragment 0 has special
powers.)
--Dave
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT