Open Stack

I seem to recall checking this when the issue was first discovered, and OVN did not appear to implement the same flow rules that resulted in the issue. I don’t have a live environment to test with, though.

James Denton
Network Engineer
Rackspace Private Cloud
james.denton at rackspace.com

From: Volodymyr Litovka <doka.ua at gmx.com>
Date: Friday, November 15, 2019 at 3:55 AM
To: James Denton <james.denton at rackspace.com>, "openstack-discuss at lists.openstack.org" <openstack-discuss at lists.openstack.org>, Slawek Kaplonski <skaplons at redhat.com>
Cc: "doka.ua at gmx.com" <doka.ua at gmx.com>
Subject: Re: [Neutron] OVS forwarding issues

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

Hi colleagues,

thanks for the pointing on this. Can anybody _assume_ whether this bug affects also ML2/OVN implementation of networking?

I was looking into OVN sometimes ago, but due to lack of resources skipped this research, now I think it makes sense to return back to this question.

Thank you.

On 11.11.2019 19:38, James Denton wrote:
Hi,

This is a known issue with the openvswitch firewall[1].

> firewall_driver = openvswitch

I recommend running iptables_hybrid until that is resolved.

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


James Denton
Network Engineer
Rackspace Private Cloud
james.denton at rackspace.com<mailto:james.denton at rackspace.com>

From: Volodymyr Litovka <doka.ua at gmx.com><mailto:doka.ua at gmx.com>
Date: Monday, November 11, 2019 at 12:10 PM
To: "openstack-discuss at lists.openstack.org"<mailto:openstack-discuss at lists.openstack.org> <openstack-discuss at lists.openstack.org><mailto:openstack-discuss at lists.openstack.org>
Cc: "doka.ua at gmx.com"<mailto:doka.ua at gmx.com> <doka.ua at gmx.com><mailto:doka.ua at gmx.com>
Subject: [Neutron] OVS forwarding issues

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

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



--

Volodymyr Litovka

  "Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191115/f7c7c6a0/attachment-0001.html>