[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Exactly my point. The "payload guaranteed" is different depending on if you are looking at 802.1d or 802.1ad. A 802.1ad "1500 byte payload" will not make it through an 802.1d switch as the 802.1d switch considers the 802.1Q shim as part of the payload - making the overall frame size larger than the 1500 byte max it is required to support.
I agree there are "lax" devices out there. Needless to say, the need for "MTU discovery" comes from those that limit MTU to the 1500 byte definition found in 802.1d.
Jonathan Sadler
________________________________________
From: James Carlson [james.d.carlson at Sun.COM]
Sent: Wednesday, April 15, 2009 8:07 AM
To: Sadler, Jonathan B.
Cc: sgai; Les Ginsberg (ginsberg); Radia Perlman; isis-wg at ietf.org; TRILL/RBridge Working Group
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Sadler, Jonathan B. writes:
> So why did James Carlson's implementation break when an 802.1ad Ethernet bridge (i.e. without .1Q extensions) was put between two RBridges? Thats what started this whole discussion...
It's because slapping an extra header on top of a 1500 octet message
tends to make it somewhat larger than 1500 octets. :-/
Right now, TRILL headers are effectively part of the payload, as far
as ordinary bridges are concerned, and are subject to the MTU
restrictions. (Unlike "overhead" information between bridges, like
VLAN tags.) If we could have access ports agree to use 1478 instead,
we'd be able to meet a 1500 restriction between RBridges.
Of course, that answer is just infeasible.
In testing, I've found that some devices limit to 1500 strictly. Some
are lax up to about 1536. Despite what standards may say about it,
there's a lot of odd stuff out in the field.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================