DHCP over a provider network

asked 2014-06-16 18:39:05 -0600

marcantonio gravatar image

updated 2014-06-17 08:07:31 -0600

I recently set up a provider network to give my VMs direct access to a storage network (see here for details). Everything works great except for DHCP assignments to the virtual interfaces on that network.

I have a physical interface on each compute node attached to my storage network. I have a bridge_mapping setup on each neutron-openvswitch-agent pointing a an OVS bridge with the physical interface in it. I have neutron-dhcp-agent running on a network node. I see the DHCP requests on the physical interfaces.

Looking on the network node the I also see the DHCP traffic on the physical interface. However, it seems that dnsmasq is running on a tap in the DHCP namespace. The DHCP requests never show up on this tap interface.

It feels like something's not configured right. Is there any special config needed for the DHCP agent to listen on a provider bridge?

Output of ovs-vsctl show:

    Bridge br-int
        Port int-br-storage
            Interface int-br-storage
        Port "tap3568596d-96"
            tag: 4095
            Interface "tap3568596d-96"
                type: internal
        Port "tapdba95eca-d3"
            tag: 1
            Interface "tapdba95eca-d3"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "qr-5d2743fe-27"
            tag: 1
            Interface "qr-5d2743fe-27"
                type: internal
    Bridge br-ex
        Port "p2p3"
            Interface "p2p3"
        Port br-ex
            Interface br-ex
                type: internal
        Port "qg-93a05791-e8"
            Interface "qg-93a05791-e8"
                type: internal
    Bridge br-storage
        Port phy-br-storage
            Interface phy-br-storage
        Port "p2p1"
            Interface "p2p1"
        Port br-storage
            Interface br-storage
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-ac1083ae"
            Interface "gre-ac1083ae"
                type: gre
                options: {in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port "gre-ac1083af"
            Interface "gre-ac1083af"
                type: gre
                options: {in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port "gre-ac1083b2"
            Interface "gre-ac1083b2"
                type: gre
                options: {in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port "gre-ac1083b0"
            Interface "gre-ac1083b0"
                type: gre
                options: {in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port "gre-ac1083b1"
            Interface "gre-ac1083b1"
                type: gre
                options: {in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "2.0.1"

Output of ovs-ofctl dump-flows br-int:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=57855.109s, table=0, n_packets=11350, n_bytes=3695441, idle_age=7, priority=2,in_port=3 actions=drop
 cookie=0x0, duration=57850.563s, table=0, n_packets=1, n_bytes=70, idle_age=57849, priority=2,in_port=2 actions=drop
 cookie=0x0, duration=57856.029s, table=0, n_packets=14354, n_bytes=9627823, idle_age=536, priority=1 actions=NORMAL

Output of ovs-ofctl dump-flows br-storage:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=57876.927s, table=0, n_packets=339, n_bytes=20638, idle_age=1025, priority=2,in_port=1 actions=drop
 cookie=0x0, duration=57877.753s, table=0, n_packets=43201, n_bytes=5755306, idle_age=2, priority=1 actions=NORMAL

Thanks, Marc

edit retag flag offensive close merge delete


from the network node, can you add the output of ovs-vsctl show and ovs-ofctl dump-flows br-int and ovs-ofctl dump-flows br-storage to the question. Also check the neutron-ovs-agent for errors.

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-06-17 01:48:40 -0600 )edit

I added the requested info. The ovs log only has a few lines like 2014-06-17 09:00:54.715 1817 INFO neutron.agent.securitygroups_rpc [req-a38200a8-ae4a-495a-aee6-5501321b286f None] Security group member updated [u'baf2d87a-7178-4ca2-9de0-3d596253ca2c']. No errors.

marcantonio gravatar imagemarcantonio ( 2014-06-17 08:08:54 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2014-06-17 09:55:19 -0600

marcantonio gravatar image

In testing something else, I deleted and recreated all neutron networks, subnets, and routers. I also stopped dhcp-agent and killed dnsmasq. Something in there seems to have fixed the issue. I noticed that there is another flow on br-storage:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=414.105s, table=0, n_packets=6, n_bytes=1002, idle_age=255, priority=4,in_port=1,dl_vlan=4 actions=strip_vlan,NORMAL
 cookie=0x0, duration=64108.885s, table=0, n_packets=771, n_bytes=48642, idle_age=394, priority=2,in_port=1 actions=drop
 cookie=0x0, duration=64109.711s, table=0, n_packets=47529, n_bytes=6270610, idle_age=0, priority=1 actions=NORMAL

Not sure what that actually means.

I HATE solutions like this...

edit flag offensive delete link more



For a flat network the ovs agent should set up a flow on br-storage to strip the vlan id. And a flow on br-int to add the vlan id. No idea why you needed to restart everything to get it working.

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-06-18 01:49:37 -0600 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-06-16 18:39:05 -0600

Seen: 562 times

Last updated: Jun 17 '14