neutron not working inside virtualbox on wi-fi

Bug #1558766 reported by Andrei-Lucian Șerb
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kolla
Fix Released
Wishlist
Andrei-Lucian Șerb

Bug Description

The current Vagrantfile connects the Neutron external interface to a Bridged Adapter, but does not set the promiscuous mode to "Allow All" (in the case of VirtualBox). This currently needs to be done manually. Promiscuous mode is needed for L2 Neutron functionality.

But also, on computers with wi-fi adapters, promiscuous mode on the VirtualBox (or maybe other hypervisors as well) NICs does not work, which means the default way of connecting the Neutron external interface to a bridged adapter, will not allow communication to and from the Nova VMs over floating IPs with any computer on the external network (except the host computer) or with the wi-fi router. This means no ability to connect to the Nova VMs and no internet access inside the Nova VMs.

According to VirtualBox documentation (excerpt):
"""Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host’s wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter’s MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines."""

A way to fix this issue is to use the NAT-Network service present in VirtualBox, which is effectively a virtual router. In this way, all communication to/from the wi-fi router is done through the virtual router. So instead of connecting the Neutron external interface to a Bridged Adapter, we connect it to a NAT Network (which needs to manually be created in advance). A downside to this fix, is that the Host Computer and the Nova VMs (when they have a floating ip attached) will not be in the same network anymore, but connecting from the Host the the Nova VMs can easily be done through setting port forwards on the virtual router.

Changed in kolla:
assignee: nobody → Andrei-Lucian Șerb (lucian-serb)
description: updated
description: updated
Changed in kolla:
status: New → In Progress
description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to kolla (master)

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

Changed in kolla:
importance: Undecided → Wishlist
milestone: none → mitaka-rc2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla (master)

Reviewed: https://review.openstack.org/294340
Committed: https://git.openstack.org/cgit/openstack/kolla/commit/?id=3b12b7b9510a184dbdfed467b64c1c925d68a8ab
Submitter: Jenkins
Branch: master

commit 3b12b7b9510a184dbdfed467b64c1c925d68a8ab
Author: Andrei-Lucian Șerb <email address hidden>
Date: Fri Mar 18 01:30:32 2016 +0200

    Attach external NIC to a NAT-Network if on Wi-Fi

    On computers with wi-fi adapters, promiscuous mode on the VirtualBox (or
    maybe other hypervisors as well) NICs does not work, which means the
    default way of connecting the Neutron external interface to a bridged
    adapter, will not allow communication to and from the Nova VMs over
    floating IPs with any computer on the external network (except the host
    computer) or with the wi-fi router. This means no ability to connect to
    the Nova VMs and no internet access inside the Nova VMs.

    According to VirtualBox documentation (excerpt): "Bridging to a wireless
    interface is done differently from bridging to a wired interface,
    because most wireless adapters do not support promiscuous mode. All
    traffic has to use the MAC address of the host’s wireless adapter, and
    therefore VirtualBox needs to replace the source MAC address in the
    Ethernet header of an outgoing packet to make sure the reply will be
    sent to the host interface. When VirtualBox sees an incoming packet with
    a destination IP address that belongs to one of the virtual machine
    adapters it replaces the destination MAC address in the Ethernet header
    with the VM adapter’s MAC address and passes it on. VirtualBox examines
    ARP and DHCP packets in order to learn the IP addresses of virtual
    machines."

    To fix this issue, a new flag has been introduced: WIFI. If true, the
    default Vagrant public network is not created anymore. Instead, the 3rd
    NIC will be connected to a NAT-Network named OSNetwork. The NAT-Network
    has a virtual gateway, which will be used to communicate with the
    external physical wi-fi router. Since Vagrant does not have a high-level
    mechanism to attach an adapter to a NAT-Network, the code uses the
    low-level Vagrant construct vm.customize which makes it provider
    specific.

    Promiscuous mode is now activated by default on the 3rd NIC.

    The WIFI flag is false by default.

    This commit only addresses VirtualBox, and it is currently unknown if
    the problem described and fixed in this commit is present in other
    hypervisors.

    DocImpact
    Closes-Bug: #1558766
    Change-Id: I0b4dbbc562d87191b2179f47b634cdd6f6361a5e
    Signed-off-by: Andrei-Lucian Șerb <email address hidden>

Changed in kolla:
status: In Progress → Fix Released
Steven Dake (sdake)
Changed in kolla:
milestone: mitaka-rc2 → newton-1
Steven Dake (sdake)
Changed in kolla:
importance: Wishlist → Medium
no longer affects: kolla/mitaka
Changed in kolla:
importance: Medium → Wishlist
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/kolla 2.0.0

This issue was fixed in the openstack/kolla 2.0.0 release.

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/kolla 1.1.0

This issue was fixed in the openstack/kolla 1.1.0 release.

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/kolla 3.0.0.0b1

This issue was fixed in the openstack/kolla 3.0.0.0b1 development milestone.

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.