[Neutron] OVS forwarding issues
James Denton
james.denton at rackspace.com
Mon Nov 11 17:38:24 UTC 2019
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
From: Volodymyr Litovka <doka.ua at gmx.com>
Date: Monday, November 11, 2019 at 12:10 PM
To: "openstack-discuss at lists.openstack.org" <openstack-discuss at lists.openstack.org>
Cc: "doka.ua at gmx.com" <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191111/e64adc6f/attachment-0001.html>
More information about the openstack-discuss
mailing list