On Fri, Jun 07, 2019 at 12:57:57PM -0700, Cong Wang wrote:
>> Well, openvswitch say that they just throw packets around and assume they're
>> valid... :-)
> _If_ the hardware switch has to pad them (according to what you said),
> why software switch doesn't?
Trust me, I'm telling them they have to deal with this, too. :-)
But you can't really assume there's a switch in the middle at all (whether
hardware nor software). You can connect a NIC to a NIC with no switch
in-between.
Normally, it's not the switch that adds the padding; it's done in the NIC
(MAC sublayer), so if the switch doesn't modify the packet, it can just send
it on. However, there are situations where it has to, like for instance when
stripping a VLAN tag (802.1Q-2005, section 6.5.1), since that makes the
packet shorter.
> Rather than arguing about this, please check what ethernet standard
> says. It would be much easier to convince others with standard.
The Ethernet standard? That's pretty clear; Ethernet frames are a minimum of
64 bytes (including FCS at the end, so 60 payload bytes including MAC
addresses etc.). IEEE 802.3-2015 4.2.3.3:
The CSMA/CD Media Access mechanism requires that a minimum frame length of
minFrameSize bits be transmitted. If frameSize is less than minFrameSize,
then the CSMA/CD MAC sublayer shall append extra bits in units of octets
(Pad), after the end of the MAC Client Data field but prior to calculating
and appending the FCS (if not provided by the MAC client). The number of
extra bits shall be sufficient to ensure that the frame, from the DA field
through the FCS field inclusive, is at least minFrameSize bits.
4A.2.3.2.4 also says, without assuming anything about CSMA/CD:
The MAC requires that a minimum frame length of minFrameSize bits be
transmitted. If frameSize is less than minFrameSize, then the MAC sublayer
shall append extra bits in units of octets (pad), after the end of the MAC
client data field but prior to calculating, and appending, the FCS (if not
provided by the MAC client). The number of extra bits shall be sufficient
to ensure that the frame, from the DA field through the FCS field
inclusive, is at least minFrameSize bits. If the FCS is (optionally)
provided by the MAC client, the pad shall also be provided by the MAC
client. The content of the pad is unspecified.
minFrameSize is defined in 4A.4.2:
minFrameSize 512 bits (64 octets)
As for what to do on undersized packets, section 4.2.9 contains this
pseudocode:
receiveSucceeding := (frameSize ≥ minFrameSize) {Reject frames too small}
To be honest, I don't see that dropping undersized frames gives any
real-world gains in the case of EoGRE, though. I'd say that the most
reasonable thing to do would be to pad on transmit, and accept undersized
frames on receive. You could argue that's wasteful for cases like the
loopback interface, but honestly, you never really know what people are going
to do with the packets (just consider the case of tcpreplay).
/* Steinar */
--
Homepage: https://www.sesse.net/
