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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev