On 6/7/2019 12:57 PM, Cong Wang wrote:
On Thu, Jun 6, 2019 at 12:36 AM Steinar H. Gunderson
<steinar+ker...@gunderson.no> wrote:
On Wed, Jun 05, 2019 at 06:17:51PM -0700, Cong Wang wrote:
Hmm, sounds like openvswitch should pad the packets in this scenario,
like hardware switches padding those on real wires.
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?
Well one thing I can think of is that there are things that can be done
in HW that become very
expensive in SW. CRC checking and packet padding are expensive in SW.
In any case, if you talk EoGRE to the vWLC directly, I doubt it accepts this,
given that it doesn't accept it on the virtual NICs.
Yes, but that's just Linux accepting something invalid, no? It doesn't mean
it should be sending it out.
Well, we can always craft our own ill-formatted packets, right? :) Does
any standard say OS has to drop ethernet frames shorter than the
minimum?
I believe you're fully allowed to accept them (although it might be
technically difficult on physical media). But that doesn't mean everybody
else has to accept them. :-)
Sure, Linux is already different with other OS'es, this also means Linux
doesn't have to reject them.
Some hardware switches pad for ETH_ZLEN when it goes through a real wire.
All hardware switches should; it's a 802.1Q demand. (Some have traditionally
been buggy in that they haven't added extra padding back when they strip the
VLAN tag.)
If so, so is the software switch, that is openvswitch?
What if the other end isn't a (virtual) switch, but a host?
Rather than arguing about this, please check what ethernet standard
says. It would be much easier to convince others with standard.
Depends on what standard says, we may need to pad on xmit path or on
forwarding path (switch), or rejecting shorter frames on receive path.
Thanks.
I am used to Ethernet switches dropping undersized and bad CRC frames.
Sure, if the incoming frame is
valid and then because of transformations in the packet due to 802.1q
specs or any other reasons (NSH comes
mind) then the packet must be padded and the correct checksum computed
by the switch. That's fine.
But if the incoming packet to the switch is malformed (undersized and
bad CRC in this case) then switches can
and probably will drop the packet.
It appears that openvswitch does not. Steinar and I are discussing that
situation on a different list.
Thanks,
- Greg
