[ovs-discuss] Small 802.1q-prepended packets not getting through to VM

Ben Pfaff blp at ovn.org
Fri Jun 7 21:57:04 UTC 2019


On Fri, Jun 07, 2019 at 02:06:45PM -0700, Gregory Rose wrote:
> 
> 
> On 6/7/2019 9:08 AM, Ben Pfaff wrote:
> > On Thu, Jun 06, 2019 at 09:31:59AM +0200, Steinar H. Gunderson wrote:
> > > On Wed, Jun 05, 2019 at 02:45:53PM -0700, Ben Pfaff wrote:
> > > > OVS, or at least the OVS kernel module, doesn't generate packets.  It
> > > > accepts them for processing from some source and then (sometimes)
> > > > delivers them to some destination.  Generally it expects that anything
> > > > that comes in is suitable to be sent back out without further
> > > > modification.
> > > Yes, I think this is the basic problem. Everybody on the path assumes that
> > > if padding is needed, that's someone else's responsibility. :-)
> > > 
> > > I can understand that when just switching packets around internally on the
> > > same host, one can take shortcuts like not padding or ignoring the checksum.
> > > (I did mention that the packets also reach the VM with the wrong checksums,
> > > right?) But when it goes out somewhere external, be it a VM or an external
> > > NIC, these things need to be in place.
> > > 
> > > > If the packet comes in on OVS internal port, then that puts the focus
> > > > slightly more on OVS.  There could be a bug in the internal port
> > > > implementation.  However, even there OVS doesn't really assemble the
> > > > packet, it comes from the Linux TCP/IP stack and the OVS internal port
> > > > just accepts it.
> > > Yes, but I suppose it sets some sort of flags for what's acceptable?
> > > At least in the case of checksums.
> > > 
> > > > I would think that the Linux host driver transmitting the packet would
> > > > ensure that it is padded so as to be acceptable for the media it will be
> > > > transmitted on (virtual media in this case).  I think that drivers for
> > > > physical media typically do this (but it's been years since I've been
> > > > familiar with the Linux network driver model).
> > > I believe physical media drivers do this, yes. Whether hostnet/virtio does
> > > it... no idea, but it would seem not. :-)
> > Greg, so far everything here is speculation on my part.  Do you have any
> > facts to inject?
> 
> I think switches should just drop undersized packets.  They should also drop
> packets with bad checksums.
> 
> Switches should not be doing any padding or checksum recalculations, that
> would impose a lot of overhead.  Switches should just switch traffic.
> 
> That's what I *think* switches should do.  What they actually do can vary a
> great deal.  I've worked with a lot of hubs and switches in the past and the
> behavior in these sorts of cases isn't always well defined.  But generally I
> think undersized frames and packets with bad checksums should just be
> dropped at the switch.  If our internal ports are not dropping
> undersized/bad checksum frames then that might be unexpected behavior and
> maybe we should investigate that more.
> 
> I can try to reproduce this scenario and educate myself a bit more about how
> OVS is dealing with these packets.

I tend to agree with most of these.  For checksums, I think it depends
on the checksum: for the Ethernet CRC, yeah, drop bad packets; for L3
and L4 checksums, though, I don't think the switch really has any
business even looking that far into the packet (and OVS doesn't).
That's not currently in question, though.

This bug report is a little different from what you describe.  The
canonical situation for a switch is that a packet comes in from
somewhere and then goes back out somewhere else.  But in this case, the
packet that comes in is coming in from the system's own TCP/IP stack.

My understanding is that packet processing for to transmit a UDP packet
through the Linux TCP/IP stack conceptually works like this:

1. Userspace calls send() with the L7 payload.

2. Kernel UDP stack assembles a UDP header followed by the L7 payload.

3. Kernel IP stack pushes an IP header.

4. Kernel L2 stack pushes an Ethernet header.

5. Kernel Ethernet driver (or a helper) adds padding, etc. as needed and
   passes it to the hardware.

   If the "hardware" is an OVS internal device, no padded is needed, so
   I assume that it doesn't get added.  So then the flow goes on:

6. OVS accepts packet and figures that it should be sent to some virtio
   device and passes it off.

7. Virtio device adds padding, etc. as needed and passes it to the VM.

Note that if the virtio device was the original destination (e.g. in #5)
then it would also have to add padding there.

This used to work fine.  Has anything changed?


More information about the discuss mailing list