Intel E810 ice and ovs issue with tagged vlan not working

[arif-ali]

We need to detect running of the following scenario on a

network driver: ice kernel: 5.4 network overlay: openvswitch neutron provider network network type vlan

In this particular scenario the traffic does not flow, even the openflows are all good

Using HWE kernel for focal solves the problem

Related issue: #430

[dosaboy]

I've been thinking through how this could be implemented and have a few thoughts/questions:

• since this check requires knowledge of what network types are in use it would typically need run on a neutron-server host but I don't know if its possible to know which network driver is in use on the compute side that way. How would you typically get that information?
• does this issue apply to kernel version range or just 5.4?
• if the check was run on the host running neutron-openvswicth-agent, is there a way to know if vlan provider networks are configured and if so how?
• are there perhaps some logs that we can use to know that the node is affected?

[arif-ali]

Here's the scenario, and potentially how we can check this

• ice driver via ethtool -i <interface>
• Ensure that it is neutron-openvswitch-agent is running
• Check on the tap devices that are there from the instances
• We can grab the data-port, bridge-mappings and vlan-ranges from /var/lib/juju/agents/unit-neutron-openvswitch-2948/charm/.juju-persistent-config, which can identify which bridges we need to check, and if vlan options are. The vlan options are only used on the neutron-server, but this helps us to identify that vlan may be used
• We can then check the destination vlans for the flow in the above data-port that is collected, and then we can see mod_vlan_vid:328, which is showing the target vlan. We could have multiple lines of these, and this is showing the target vlan being used

$ sudo ovs-ofctl dump-flows br-data
 cookie=0x39ba2001971757d4, duration=1192372.398s, table=0, n_packets=1035283, n_bytes=43496614, priority=4,in_port="phy-br-data",dl_vlan=5 actions=mod_vlan_vid:328,NORMAL
 cookie=0x39ba2001971757d4, duration=1192375.985s, table=0, n_packets=6, n_bytes=252, priority=2,in_port="phy-br-data" actions=drop
 cookie=0x39ba2001971757d4, duration=1192375.986s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL

• We can also check the PCI card, and see if it is the E810. The bus-info from the ethtool -i, we can send to lspci -s, which will give us that information from the VPD

EDIT:

We may be able to grab, if the hypervisor has any vlans configured in ovs

$ grep network_type=vlan sos_commands/openvswitch/ovsdb-client_-f_list_dump
other_config        : {net_uuid="93cd6964-ea12-4579-8a43-8ff059f2c7f5", network_type=vlan, physical_network=physnet1, segmentation_id="328", tag="5"}
other_config        : {net_uuid="93cd6964-ea12-4579-8a43-8ff059f2c7f5", network_type=vlan, physical_network=physnet1, segmentation_id="328", tag="5"}

[muthuramanataya]

In some other use case, I found this problem and fixed by turn off the setting "rx-vlan-offload" like below

ethtool -K enp131s0f0 rx-vlan-filter off

This problem can not be seen when interface set to PROMISC flag.