Kilo: br-ex blocking the connection to the cloud external network
I think their is a bug in br-ex (ovs bridge)
I built my cloud with 3 nodes using Kilo release, everything is working fine except the external network in network node. network node consist of 3 NICs: eth0: management network, eth1: tunnel network, eth2: added to br-ex and connected to external network.
my floating IP address range is: 192.168.100.101-200/24 active IPs: br-ex: 192.168.100.100 cloud router gw: 192.168.100.101 cloud instance(vm): 192.168.100.102
I setup an external host Debian: 192.168.100.10/24 to test connectivity to cloud external network.
the case is when I ping the cloud router gw and cloud vm from network node it successfully connected, however, only br-ex can be connected from the external host while any other floating ip addresses is blocked by br-ex (tcpdum result).
Did any one faced the same issue? any one have a clue, why br-ex is not forwarding the traffic outside network node? any one managed to fix it? Please help, its critical for me to solve it as soon as possible.
here some detailed configuration of the system.
/etc/network/interfaces
auto eth0 iface eth0 inet static
address 192.168.137.21
netmask 255.255.255.0
gateway 192.168.137.1
nameserver 8.8.8.8
auto eth1 iface eth1 inet static
address 10.0.1.21
netmask 255.255.255.0
auto eth2 iface eth2 inet manual
up ip link set dev $IFACE up
up ifconfig $IFACE promisc
down ip link set dev $IFACE down
auto br-ex iface br-ex inet static
up ifconfig $IFACE promisc
address 192.168.100.100
netmask 255.255.255.0
gateway 192.168.100.1
nameserver 8.8.8.8
openstack@network:~$ sudo ovs-vsctl show
147b1c24-83c4-4a32-aa0a-3c2dd0e309f2
Bridge br-tun
fail_mode: secure
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a00011f"
Interface "gre-0a00011f"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.0.1.21", out_key=flow, remote_ip="10.0.1.31"}
Port br-tun
Interface br-tun
type: internal
Bridge br-ex
Port "qg-b6093823-1f"
Interface "qg-b6093823-1f"
type: internal
Port "eth2"
Interface "eth2"
Port br-ex
Interface br-ex
type: internal
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Bridge br-int
fail_mode: secure
Port "qr-35c7dc18-57"
tag: 1
Interface "qr-35c7dc18-57"
type: internal
Port "tap4e8a4128-1d"
tag: 3
Interface "tap4e8a4128-1d"
type: internal
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
Port "qr-ef9fd3b6-e2"
tag: 3
Interface "qr-ef9fd3b6-e2"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "tapf787d71a-7f"
tag: 2
Interface "tapf787d71a-7f"
type: internal
Port "tap75f81849-19"
tag: 1
Interface "tap75f81849-19"
type: internal
Port "qr-c598ce66-1d"
tag: 2
Interface "qr-c598ce66-1d"
type: internal
Port br-int
Interface br-int
type: internal
ovs_version: "2.3.2"
openstack@network:~$ sudo ip netns exec
qrouter-8893f782-f200-493d-b572-f0062a9a1917
ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu
65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host ...
My recommendations:
Install a newer version of OpenStack; Kilo is ancient.
Trace traffic on the qg and qr interfaces in the router namespace.
Review the ML2 config, especially the provider network.
I have a Newton installation with a centralized router on OVS, like you (I think). My br-ex has a single flow and seems to function like a normal bridge:
My flow:
mine is having two flow one as the one you have and the other one is a drop action for the peer connection between br-ex and br-int. the thing I compared it with a working cloud which is having the same as what I have (2 flows).