[Neutron] OVS forwarding issues

Slawek Kaplonski skaplons at redhat.com
Tue Nov 12 08:42:45 UTC 2019


Hi,

If You are using ovs firewall driver, it is known issue there. See bug [1] for
details. There is proposal how to fix it in [2] but it's not perfect and still
require some more work to do.

[1] https://bugs.launchpad.net/neutron/+bug/1732067
[2] https://bugs.launchpad.net/neutron/+bug/1841622

On Mon, Nov 11, 2019 at 07:06:43PM +0200, Volodymyr Litovka wrote:
> Dear colleagues,
> 
> just faced an issue with Openvswitch, which looks strange for me. The
> problem is that any particular VM receives a lot of packets, which are
> unicasted:
> - from other VMs which reside on the same host (let's name them "local VMs")
> - to other VMs which reside on other hosts (let's name them "remote VMs")
> 
> Long output from "ovs-ofctl dump-flows br-int" which, as far as I can
> narrow, ends there:
> 
> # ovs-ofctl dump-flows br-int |grep " table=94," |egrep
> "n_packets=[123456789]"
>  cookie=0xaf6b1435fe826bdf, duration=2952350.695s, table=94,
> n_packets=291494723, n_bytes=40582103074, idle_age=0, hard_age=65534,
> priority=1 actions=NORMAL
> 
> coming to normal processing (classic MAC learning). Looking into br-int
> MAC-table (ovs-appctl fdb/show br-int) shows, that there are really no
> MAC addresses of remote VMs and br-int behaves in the right way,
> flooding unknown unicast to all ports in this L2 segment.
> 
> Of course, there is br-tun which connected over vxlan to all other hosts
> and to br-int:
> 
>     Bridge br-tun
>         Controller "tcp:127.0.0.1:6633"
>             is_connected: true
>         fail_mode: secure
>         Port "vxlan-0a960008"
>             Interface "vxlan-0a960008"
>                 type: vxlan
>                 options: {df_default="true", in_key=flow,
> local_ip="10.150.0.5", out_key=flow, remote_ip="10.150.0.8"}
>         [ ... ]
>         Port br-tun
>             Interface br-tun
>                 type: internal
>         Port patch-int
>             Interface patch-int
>                 type: patch
>                 options: {peer=patch-tun}
> 
> but MAC table on br-tun is empty as well:
> 
> # ovs-appctl fdb/show br-tun
>  port  VLAN  MAC                Age
> #
> 
> Finally, packets get to destination, while being copied to all ports on
> source host, which is serious security issue.
> 
> I do not think so conceived by design, I rather think we missed
> something in configuration. Can anybody point me where we're wrong and
> help with this issue?
> 
> We're using Openstack Rocky and OVS 2.10.0 under Ubuntu 16.04. Network
> configuration is:
> 
> @controller:
> # cat /etc/neutron/plugins/ml2/ml2_conf.ini |egrep -v "^$|^#"
> [DEFAULT]
> verbose = true
> [ml2]
> type_drivers = flat,vxlan
> tenant_network_types = vxlan
> mechanism_drivers = l2population,openvswitch
> extension_drivers = port_security,qos,dns_domain_ports
> [ml2_type_flat]
> flat_networks = provider
> [ml2_type_geneve]
> [ml2_type_gre]
> [ml2_type_vlan]
> [ml2_type_vxlan]
> vni_ranges = 400:400000
> [securitygroup]
> firewall_driver = openvswitch
> enable_security_group = true
> enable_ipset = true
> 
> @agent:
> # cat /etc/neutron/plugins/ml2/openvswitch_agent.ini |egrep -v "^$|^#"
> [DEFAULT]
> verbose = true
> [agent]
> tunnel_types = vxlan
> l2_population = true
> arp_responder = true
> extensions = qos
> [ovs]
> local_ip = 10.150.0.5
> bridge_mappings = provider:br-ex
> [securitygroup]
> firewall_driver = openvswitch
> enable_security_group = true
> enable_ipset = true
> [xenapi]
> 
> Thank you.
> 
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat




More information about the openstack-discuss mailing list