Ask Your Question
1

OVS bridge not passing traffic

asked 2013-10-24 13:18:08 -0500

larsks gravatar image

updated 2013-10-24 13:39:13 -0500

I have a two-node Grizzly deployment using Quantum + GRE tunnels. After rebooting the network controller, instances on the compute node are no longer able to reach the default gateway.

The network is defined in quantum:

# quantum net-list
+--------------------------------------+--------+------------------------------------------------------+
| id                                   | name   | subnets                                              |
+--------------------------------------+--------+------------------------------------------------------+
| 42888e36-6201-4a61-b3e9-57780d5f0be2 | public | bc281373-a3ab-4451-9027-524fe14dcb5b 172.24.4.224/28 |
| d8c7e39a-47bd-46da-aff7-255f6bac55cb | net0   | e2dddf26-2407-4c38-b69a-71564aea67d8 10.0.0.0/24     |
+--------------------------------------+--------+------------------------------------------------------+

As is the router:

# quantum router-list
+--------------------------------------+-----------+--------------------------------------------------------+
| id                                   | name      | external_gateway_info                                  |
+--------------------------------------+-----------+--------------------------------------------------------+
| a3d7ec8e-3c4a-45f3-bade-25f0e69138cd | pubrouter | {"network_id": "42888e36-6201-4a61-b3e9-57780d5f0be2"} |
+--------------------------------------+-----------+--------------------------------------------------------+

And the appropriate network namespace exists:

# ip netns
qdhcp-d8c7e39a-47bd-46da-aff7-255f6bac55cb
qrouter-a3d7ec8e-3c4a-45f3-bade-25f0e69138cd

The output of ovs-vsctl show looks like this:

8caee4f9-07b7-4477-ba77-73a9d20c574d
    Bridge br-tun
        Port "gre-2"
            Interface "gre-2"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.9.8.10"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "tap1febee5a-7e"
            Interface "tap1febee5a-7e"
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tap5accf990-b0"
            tag: 1
            Interface "tap5accf990-b0"
        Port "tapf246dd31-e0"
            tag: 1
            Interface "tapf246dd31-e0"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    ovs_version: "1.11.0"

With an instance at 10.0.0.2 on the compute node running ping 10.0.0.1, I can see ARP packets coming across the GRE tunnel:

# tcpdump -i eth1 -n
13:34:25.724597 IP 10.9.8.10 > 10.9.8.1: GREv0, key=0x2, length 54: ARP,
  Request who-has 10.0.0.1 tell 10.0.0.2, length 28

And I can see them showing up on tapf246dd31-e0 (which is on br-int):

# tcpdump -i tapf246dd31-e0 -n
13:35:30.813915 ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 28

But I do not see them on tap5accf990-b0, which is what connects to the router namespace. I'm not sure what to do to further debug this problem. The packets are obviously getting as far as tapf246dd31-e0, and tap5accf990-b0 is on the same bridge with the same tag but is apparently not seeing the packets.

What else should I look at?

UPDATE: I should emphasize that this was working prior to rebooting the network controller. Also, instances are perfectly capable of reaching the DHCP server at 10.0.0.3 (inside qdhcp-d8c7e39a-47bd-46da-aff7-255f6bac55cb).

edit retag flag offensive close merge delete

Comments

What os and version is this? Ovs shows 2 interfaces with prefix tap - I guess you must be using veths to connect them to their namespaces. Try tcpdump on the interfaces inside the namespaces: do 'sudo ip netns exec qrouter-a3d7ec8e-3c4a-45f3-bade-25f0e69138cd ip address'

darragh-oreilly gravatar imagedarragh-oreilly ( 2013-10-24 13:35:31 -0500 )edit

This is on RHEL 6.4 (using the RHOS 3.0 distribution, which includes the necessary network namespace support). `tcpdump` on the network interface inside the router namespace does not show any traffic.

larsks gravatar imagelarsks ( 2013-10-24 13:38:07 -0500 )edit

I don't know. I'd check the l3-agent and ovs-agent logs for errors. And syslog after that.

darragh-oreilly gravatar imagedarragh-oreilly ( 2013-10-24 14:12:57 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
1

answered 2013-10-24 15:05:17 -0500

larsks gravatar image

This isn't really an answer, but it solved the problem:

Running...

ovs-vsctl del-port br-int tap5accf990-b0

...followed by...

ovs-vsctl add-port br-int tap5accf990-b0 tag=1

Got things working again. If someone out there can identify the root cause for this behavior that would be awesome.

edit flag offensive delete link more

Comments

Have you got quantum-ovs-cleanup set to run at boot time?

darragh-oreilly gravatar imagedarragh-oreilly ( 2013-10-24 15:12:27 -0500 )edit

Just checked, and yes.

larsks gravatar imagelarsks ( 2013-10-24 15:18:21 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-10-24 13:18:08 -0500

Seen: 4,328 times

Last updated: Oct 24 '13