VM, on a self service private network, issues DHCP DISCOVER and receives no response.

Using the OpenStack-pike installation guide, built a CentOS 7.4 controller with the following:

  openstack-dashboard-12.0.1-1.el7.noarch
  openstack-glance-15.0.0-2.el7.noarch
  openstack-keystone-12.0.0-1.el7.noarch
  openstack-neutron-11.0.2-2.el7.noarch
  openstack-neutron-common-11.0.2-2.el7.noarch
  openstack-neutron-linuxbridge-11.0.2-2.el7.noarch
  openstack-neutron-ml2-11.0.2-2.el7.noarch
    option 2, self service network
  openstack-nova-api-16.0.3-2.el7.noarch
  openstack-nova-common-16.0.3-2.el7.noarch
  openstack-nova-conductor-16.0.3-2.el7.noarch
  openstack-nova-console-16.0.3-2.el7.noarch
  openstack-nova-novncproxy-16.0.3-2.el7.noarch
  openstack-nova-placement-api-16.0.3-2.el7.noarch
  openstack-nova-scheduler-16.0.3-2.el7.noarch
  tcpdump

and a single CentOS 7.4 compute node with:

 openstack-neutron-common-11.0.2-2.el7.noarch
  openstack-neutron-linuxbridge-11.0.2-2.el7.noarch
  openstack-nova-common-16.0.3-2.el7.noarch
  openstack-nova-compute-16.0.3-2.el7.noarch
  tcpdump

Then, through the dashboard as demo user:
  1. created a private network/subnet.
  2. created a router and added one interface from each network, provider and private.
  3. instantiated Cirros image with private network.
  4. dashboard log and console show that "cirros-dhcpc up eth0" (dhcp discover) is never answered.

In this condition, with the VM running but receiving no DHCP response, the bridge configuration
on the compute node is:

  (showing just the private network.)
  bridge name bridge id STP enabled interfaces
  brq759ebc61-66 8000.32a543821403 no tapf25a24c9-7d
                                                        vxlan-68
and on the controller:

  (vxlan-68 is on the private network, and em1 is on the provider network (see below).)
  bridge name bridge id STP enabled interfaces
  brq759ebc61-66 8000.2ef1b39d92f3 no tap65e6263a-50
                                                        tapd425267a-25
                                                        vxlan-68

  brqe30da05a-f7 8000.246e96405630 no em1
                                                        tap2a99cfa6-95
                                                        tapd535e624-b8

Using tcpdump, it is possible to trace the path of the DHCP DISCOVER from the VM to where it
is dropped on the controller. The second attachment contains a diagram that illustrates the flow.

The bridge net filtering is normally disabled by switches in /proc/sys/net/bridge/bridge-nf-*; six switches in all.
However, under os-pike, the neutron-linuxbridge-agent is doing the following:

o Enabling bridge-nf-call-iptables and bridge-nf-call-ip6tables on both the controller and on the compute node.
o On the compute node only, creating the following iptables rule:

  -A neutron-linuxbri-o25709c53-7 -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -m comment --comment "Allow DHCP client traffic." -j RETURN

  This iptables rule allows the DHCP DISCOVER packet to traverse the bridge on the compute node, only to be dropped on the controller.

Turning the switches off on the controller (as is the case under os-liberty) allows the packet to continue and the VM to get its' IP address.

The question is, how shoud this work? Should neutron-linuxbridge-agent:

o NOT enable the switches on the controller, as per os-liberty, or should it
o create the "DHCP ALLOW" iptables rule on the controller?

Attachment: A text file containing the switch settings and all iptable rules for all name spaces, from:

o os-pike controller
o os-pike compute
o os-liberty controller
o os-liberty compute