quantum agent using a namespace does not work with nec plugin

Bug #1048681 reported by Akihiro Motoki
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Akihiro Motoki

Bug Description

DHCP agent with namespace does work with NEC OpenFlow plugin.

NEC plugin uses an Open vSwitch as an OpenFlow switch and the bug is basically from OVS behavior in OpenFlow mode.

1) The current OVSInterfaceDriver creates an port with type=internal using ovs-vsctl add-port. At this timing the port is UP.
2) Next the created is moved to the dhcp-agent namespace. Then the port status becomes DOWN.

$ sudo ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:000072a1d4e84a4e
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
 1(tap7d6fba03-f9): addr:f0:00:00:00:00:00
     config: PORT_DOWN
     state: LINK_DOWN
 LOCAL(br-int): addr:72:a1:d4:e8:4a:4e
     config: PORT_DOWN
     state: LINK_DOWN
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0

This happens since the created port disappears from the default namespace.
OVS vswitchd log /var/log/openvswitch/ovs-vswitchd.log says "

Usual OpenFlow controllers respect the OpenFlow port status. Since DHCP server (dnsmasq) is connected to the down port, DHCP server disappears from the virtual network.

This behavior can be avoided if we use a similar approach used in BridgeInterfaceDriver, i.e., we first create a veth pair, add one veth device to OVS and move the other veth device to a network namespace.

Akihiro Motoki (amotoki)
summary: - NEC plugin does work with namespaces
+ quantum agent using a namespace does not work with nec plugin
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

Fix proposed to branch: master
Review: https://review.openstack.org/12714

Changed in quantum:
status: New → In Progress
Revision history for this message
dan wendlandt (danwent) wrote :

Hi Akihiro,

In general, I'd prefer a change that didn't increase the set of vif drivers unless we absolutely have to, but we can if needed.

Does a simple 'ovs-ofctl mod-port tap7d6fba03-f9 up' after the port is moved to the namespace work?

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Unfortunately all of 'ovs-ofctl mod-port <dev> up', ifconfig <dev> up, and 'ip link set <dev> up'
do not affect the status of the port.

I made a simple test just with OVS 1.4.0 from Ubuntu 12.04.
http://paste.openstack.org/show/20817/
According to the ovs-vswitchd log, the port moved to the namespace is invisible to OVS. /var/log/openvswitch/ovs-vswitchd.log says "ioctl(SIOCGIFINDEX) on port1 device failed: No such device" and "failed to get flags for network device port1: No such device".

Of course I agreed that in general it is not a good direction to increase variations of interface drivers.

dan wendlandt (danwent)
Changed in quantum:
milestone: none → folsom-rc1
importance: Undecided → Medium
Revision history for this message
Mark McClain (markmcclain) wrote :

If we're going to go the veth route, I think we should just fix OVSInterfaceDriver to manage namespace devices differently vs create another variant of it.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Thanks for the comment.
If we use the veth approach, we can modify OVSInterfaceDriver to manage namaspace device differently.
In this case, I think we need to introduce a new config option. (I do not prefer to add an mode parameter to plug/unplug since a caller of plug/unplug do not know which mode should be used.)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/12714
Committed: http://github.com/openstack/quantum/commit/aa5a7aaf47b6cf97a6f35934f68570ecfc16bd4e
Submitter: Jenkins
Branch: master

commit aa5a7aaf47b6cf97a6f35934f68570ecfc16bd4e
Author: Akihiro MOTOKI <email address hidden>
Date: Mon Sep 10 22:21:35 2012 +0900

    Add a new interface driver OVSVethInterfaceDriver.

    Fixes bug 1048681

    This commit fixes a bug that quantum agent using a namespace does not
    work with NEC plugin. NEC plugin uses an Open vSwitch as an OpenFlow switch,
    but an OVS port created by ovs-vsctl add-port becomes down when the port is
    moved to some network namespace. Usual OpenFlow controllers respect the
    OpenFlow port status. Since DHCP server (dnsmasq) is connected to the down
    port, DHCP server disappears from the virtual network.

    This behavior can be avoided if we use a similar approach used in
    BridgeInterfaceDriver, i.e., we first create a veth pair, add one veth device
    to OVS and move the other veth device to a network namespace. To accomplish it
    this patch introduces a new interface driver OVSVethInterfaceDriver.

    In addition, this patch adds a 'prefix' paramter to unplug(). When deleting
    a veth pair, a veth device added to OVS bridge is not removed automatically.
    Thus we need a mean to know the veth device name from a device_name to be
    removed. It is the reason to add 'prefix' parameter to unplug().

    Change-Id: I3f4eae371a27a3171a6a8c9e38ddc9354ed1b6b0

Changed in quantum:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in quantum:
milestone: folsom-rc1 → 2012.2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

Fix proposed to branch: master
Review: https://review.openstack.org/14323

Changed in quantum:
status: Fix Released → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/14323
Committed: http://github.com/openstack/quantum/commit/95c4d0e82f92fdf6d2a4e93453df3b831193f54a
Submitter: Jenkins
Branch: master

commit 95c4d0e82f92fdf6d2a4e93453df3b831193f54a
Author: Akihiro MOTOKI <email address hidden>
Date: Fri Sep 28 22:05:50 2012 +0900

    Merge OVSVethInterfaceDriver into OVSInterfaceDriver

    Fixes bug 1049385

    Due to some issues using OVS internal interfaces across namespaces
    with OpenFlow controllers (bug 1048681), a patch introduced the
    OVSVethInterfaceDriver in addition to the base OVSInterfaceDriver.
    However, OVSVethInterfaceDriver is just a variation of OVSInterfaceDriver
    and the difference is how to create an interface (OVS internal vs veth).
    This patch merge OVSVethInterfaceDriver into OVSInterfaceDriver
    by introducing a new flag 'ovs_use_veth' (which defaults to False).

    Change-Id: Ie8b01e6776bf703f72a9e2a471b24e126f6e2322

Changed in quantum:
status: In Progress → Fix Committed
Akihiro Motoki (amotoki)
Changed in quantum:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.