Tom Samplonius wrote: > Probably wouldn't be affective anyhow. L2 switches assume that they can > encapsulate 1500 byte ethernet frames into 802.1q properly. It is part of > the 802.1q standard. If the NIC can't understand the frame because it is > now 1504 bytes, it will be a layer 2 discard. There will be no ICMP > message sent in this case. You could argue that the switch should also be > configured with a 1456 byte MTU to allow for the addition of the 802.1q > encapsulation. But a L2 switch is not going to send a L3 message like a > ICMP "unable to fragment" fragment. So MTU detection buys you nothing. > > The fact of the matter is, if you use 802.1q encapsulation, the total > frame size can be 1504. That is the standard. This is truly evil. I would suggest, though, that L2 switches shouldn't be boundaries for this type of encapsulation, if this is the case. Worst case, though, an attempt at PMTU through a switch that did this anyway should end up with whatever MTU the host has setup. I expect that the 802.1q encapsulation of 1500 MTU packets (yielding 1504 MTU packets on the wire) was actually intended to operate in switch-to-switch trunking, not sitch-to-host trunking. Effectively, this means the machine that's doing it's own VLAN stuff is really a trunk endpoint, not a traditional ethernet endpoint. I have no problem with this. I'm just pointing out that not all cards will be able to support the idea, and that if you depend on arbitrary cards supporting it, you are going to get shot in the foot. You'll agree that a PMTU discovery through an L2 switch that was doing 802.1q to a machine with a card that couldn't handle more than 1500 MTU total, should result in a discovery of "1496" and not "1500", right? -- TerryReceived on Sat Aug 02 2003 - 15:29:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:17 UTC