Open Stack

First let me make sure I understand what this section (
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
) is trying to say.  The second paragraph is saying that some 
infrastructure provider has allocated a VLAN tag (and the later display of 
localrc contents uses 2010 as that tag) and an address range (later seen 
to be 203.0.113.0/24) to use on that VLAN on provider_net.  The exhibited 
localrc contents also say that tenant networks can be created, using VLAN 
tags drawn from the range 3001:4000.  Those localrc contents do not 
explicitly say which ethernet --- provider_net or control_plane --- will 
carry those tenant VLANs.  Which ethernet do you think those localrc 
contents imply will carry the tenant VLANs?

Second, I tested this using stable/liberty on Ubuntu 14.04.03, and got a 
few surprises.  I did exactly as described by that section, starting from 
a "physical network setup" as described there (but it was actually 
virtual, using VirtualBox), and using the localrc contents exhibited there 
except patched to fix bugs 
https://bugs.launchpad.net/devstack/+bug/1508195 and 
https://bugs.launchpad.net/devstack/+bug/1508202 (the latter by sadly 
stipulating IP_VERSION=4).  After creating the controller, compute1, and 
compute2 I looked at `ovs-vsctl show` on the controller, and found that 
br-tun had two VxLan ports (see display below).  This surprised me because 
I thought that VxLan can itself handle multiple hosts, it is not just 
point-to-point.

    Bridge br-tun
        fail_mode: secure
        Port "vxlan-0a000003"
            Interface "vxlan-0a000003"
                type: vxlan
                options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.3"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0a000004"
            Interface "vxlan-0a000004"
                type: vxlan
                options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.4"}
        Port br-tun
            Interface br-tun
                type: internal

My second surprise is that the path from controller to the VM's host goes 
over the control_plane network --- somewhat contrary to its name!

My third surprise came after I made a VM on the provider network and tried 
to ping it from the router.  I got no response.  A little investigation 
shows that the router's ARP request for the VM gets lost somewhere between 
br-int and br-tun.  `tcpdump -nne -i br-int` on the controller shows the 
ARP requests appearing with VLAN tag 1 (which is right, the external VLAN 
tags are translated to internal host-local tags on br-int), and no ARP 
replies.  OTOH, `tcpdump -nne -i br-tun` does not even find the ARP 
requests.

Digging a little deeper, I looked at the OpenFlow tables on the 
controller.  It looks like the flow table for br-tun does indeed prescribe 
that all traffic coming from outside be dropped!  Here is the output from 
`ovs-appctl bridge/dump-flows br-tun`:

duration=23916s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=3,actions=resubmit(,4)
duration=39904s, priority=1, n_packets=82, n_bytes=7025, 
priority=1,in_port=1,actions=resubmit(,2)
duration=36711s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=2,actions=resubmit(,4)
duration=39904s, priority=0, n_packets=7, n_bytes=558, 
priority=0,actions=drop
table_id=2, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,20)
table_id=2, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,22)
table_id=3, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=4, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=6, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=10, duration=39904s, priority=1, n_packets=0, n_bytes=0, 
priority=1,actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xb64bc7164f7e1137,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
table_id=20, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=resubmit(,22)
table_id=22, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x3,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=1, n_bytes=90, 
priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x2,actions=drop

By examining `ovs-vsctl list Interface` I can see that patch-int is 
OpenFlow port 1, vxlan-0a000003 is port 2, and vxlan-0a000004 is port 3. 
So the router sends the ARP request to the ethernet broadcast address, it 
comes into the controller through eth1 with VLAN tag 2010, and goes 
through br-ex to br-int --- where it appears with VLAN tag 1 (I can see 
both of those with `tcpdump`).  The second line of the flow dump above 
shows there have been 82 such packets.  They got resubmitted to table 2, 
where they all matched the second rule of that table and got resubmitted 
to table 22 --- which dropped them all.

Did I do something wrong, or is this a bug --- and, if so, is it in 
DevStack doc, DevStack scripts, or Neutron?

(Voluminous details available, if knew the preferred way to transfer 
them.)

Thanks,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/ed0a354c/attachment.html>