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

[Gregory Rose]

On 6/12/2019 10:09 AM, Steinar H. Gunderson wrote:
> On Wed, Jun 12, 2019 at 09:53:02AM -0700, Gregory Rose wrote:
>> You clipped this part:
>> root at ubuntu-1604-base:~# ovs-ctl start
>>   * Starting ovsdb-server
>>   * system ID not configured, please use --system-id
>>   * Configuring Open vSwitch system IDs
>>   * Starting ovs-vswitchd
>>   * Enabling remote OVSDB managers
>> root at ubuntu-1604-base:~# ovs-vsctl show
>> 6be291a9-6bab-4fff-bda9-7f54335b4884 <--------------------------
>>      ovs_version: "2.11.90" <-------------------------
> I don't understand. You didn't ask me for it at all.
>
>>> allow-ovsbr1 enp57s3
>>> iface enp57s3 inet manual
>>> 	ovs_bridge ovsbr1
>>> 	ovs_type OVSPort
>>> 	ovs_options tag=1
>> Note the physical interface being added to the ovsbr1 bridge here with tag
>> of 1 (vlan ID 1)
> The enp57s3 interface isn't relevant at all. The bug was reported way before
> I set up that interface, or even moved to the machine with it.
>
>>> # LAN
>>> allow-ovsbr1 vlan1
>>> iface vlan1 inet static
>>> 	address 10.0.0.1
>>> 	netmask 255.255.255.0
>>> 	ovs_bridge ovsbr1
>>> 	ovs_type OVSIntPort
>>> 	ovs_options tag=1
>> And here is your vlan1 interface on vlan ID 1.  You've created the interface
>> here and then added it to the bridge.
>>
>> So interface vlan1 is the originator of your packets.  You do not send
>> packets on an 'internal' OVS port, you send them
>> on this interface  and then it is bridged to OVS.
> OK. This is a distinction I wasn't aware of at all; I'm sure it's important
> somehow, but I still fail to see how the interface/port distinction is relevant
> in this case.

In reference to switching/bridging the distinction relevant and 
important.  In this case, it is important to
understand the OVS does not originate your packets.

>
>> Since you have two
>> physical devices enp57s3 and enp57s2 on the ovsbr1
>> bridge the underlying bridging software will switch your packets accordingly
>> out to the network or locally across the
>> bridge if appropriate but has nothing to do with originating them. It is up
>> to those interfaces to pad and  properly
>> checksum their packets before forwarding them on to the bridge.
> enp57s2 and enp57s3 are not involved in this at all. The traffic is coming
> from vlan1 and going into vnet1.

They're bridged in and can act as underlying transport for your vlan1 
interface.

>
>> You can find out the drivers for those interfaces by poking around in
>> /sys/class/net but I'd presume from what you've
>> shown here that it will be the 802.1q driver.
> lrwxrwxrwx 1 root root 0 juni   6 16:12 /sys/class/net/enp57s2/device/driver -> ../../../../../bus/pci/drivers/bnx2
>
> vlan1 and vnet1 do not have /sys/class/net/<foo>/device. But vlan1 has a MAC
> address of 3e:29:2a:06:95:d3, which doesn't show up in any OUI database I've
> seen.
>
> My question still stands; when I do this:
>
>    root at blackhole:~# ovs-vsctl add-port ovsbr1 foobar -- set Interface foobar type=internal
>
> I get an interface called foobar. What kind of interface is it?
> If OVS isn't the right address for bugs related to it, who would be?
>
> /* Steinar */

The underlying driver for the internal type interface is the tap 
driver.  So I it would be the tap driver in this case that might
be giving you headaches.  Or the tap driver is creating good packets but 
they're getting corrupted or malformed elsewhere.
I can't say.  What I can say is that OVS isn't originating the packets.

More information you might find useful here:

https://arthurchiao.github.io/blog/ovs-deep-dive-6-internal-port/

Thanks,

- Greg