<font size=2 face="sans-serif">First let me make sure I understand what
this section (</font><a href="http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks"><font size=2 color=blue face="sans-serif">http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks</font></a><font size=2 face="sans-serif">)
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?</font><br><br><font size=2 face="sans-serif">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 </font><a href="https://bugs.launchpad.net/devstack/+bug/1508195"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/devstack/+bug/1508195</font></a><font size=2 face="sans-serif">and </font><a href="https://bugs.launchpad.net/devstack/+bug/1508202"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/devstack/+bug/1508202</font></a><font size=2 face="sans-serif">(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 <u>two</u> 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.</font><br><br><font size=2 face="Menlo-Regular"> Bridge br-tun</font><br><font size=2 face="Menlo-Regular"> fail_mode:
secure</font><br><font size=2 face="Menlo-Regular"> Port
"vxlan-0a000003"</font><br><font size=2 face="Menlo-Regular">
Interface "vxlan-0a000003"</font><br><font size=2 face="Menlo-Regular">
type: vxlan</font><br><font size=2 face="Menlo-Regular">
options: {df_default="true", in_key=flow,
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.3"}</font><br><font size=2 face="Menlo-Regular"> Port
patch-int</font><br><font size=2 face="Menlo-Regular">
Interface patch-int</font><br><font size=2 face="Menlo-Regular">
type: patch</font><br><font size=2 face="Menlo-Regular">
options: {peer=patch-tun}</font><br><font size=2 face="Menlo-Regular"> Port
"vxlan-0a000004"</font><br><font size=2 face="Menlo-Regular">
Interface "vxlan-0a000004"</font><br><font size=2 face="Menlo-Regular">
type: vxlan</font><br><font size=2 face="Menlo-Regular">
options: {df_default="true", in_key=flow,
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.4"}</font><br><font size=2 face="Menlo-Regular"> Port
br-tun</font><br><font size=2 face="Menlo-Regular">
Interface br-tun</font><br><font size=2 face="Menlo-Regular">
type: internal</font><br><br><font size=2 face="sans-serif">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!</font><br><br><font size=2 face="sans-serif">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.</font><br><br><font size=2 face="sans-serif">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 `</font><tt><font size=3>ovs-appctl
bridge/dump-flows br-tun</font></tt><font size=2 face="sans-serif">`:</font><br><br><tt><font size=2>duration=23916s, priority=1, n_packets=0, n_bytes=0,
priority=1,in_port=3,actions=resubmit(,4)</font></tt><br><tt><font size=2>duration=39904s, priority=1, n_packets=82, n_bytes=7025,
priority=1,in_port=1,actions=resubmit(,2)</font></tt><br><tt><font size=2>duration=36711s, priority=1, n_packets=0, n_bytes=0,
priority=1,in_port=2,actions=resubmit(,4)</font></tt><br><tt><font size=2>duration=39904s, priority=0, n_packets=7, n_bytes=558,
priority=0,actions=drop</font></tt><br><tt><font size=2>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)</font></tt><br><tt><font size=2>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)</font></tt><br><tt><font size=2>table_id=3, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,actions=drop</font></tt><br><tt><font size=2>table_id=4, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,actions=drop</font></tt><br><tt><font size=2>table_id=6, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,actions=drop</font></tt><br><tt><font size=2>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</font></tt><br><tt><font size=2>table_id=20, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,actions=resubmit(,22)</font></tt><br><tt><font size=2>table_id=22, duration=39904s, priority=0, n_packets=82,
n_bytes=7025, priority=0,actions=drop</font></tt><br><tt><font size=2>table_id=254, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,reg0=0x3,actions=drop</font></tt><br><tt><font size=2>table_id=254, duration=39904s, priority=0, n_packets=1,
n_bytes=90, priority=0,reg0=0x1,actions=controller(reason=no_match)</font></tt><br><tt><font size=2>table_id=254, duration=39904s, priority=0, n_packets=0,
n_bytes=0, priority=0,reg0=0x2,actions=drop</font></tt><br><br><font size=2 face="sans-serif">By examining `ovs-vsctl list Interface`
I can see that patch-int is OpenFlow port 1, </font><font size=2 face="Menlo-Regular">vxlan-0a000003</font><font size=2 face="sans-serif">is port 2, and </font><font size=2 face="Menlo-Regular">vxlan-0a000004</font><font size=2 face="sans-serif">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.</font><br><br><font size=2 face="sans-serif">Did I do something wrong, or is this
a bug --- and, if so, is it in DevStack doc, DevStack scripts, or Neutron?</font><br><br><font size=2 face="sans-serif">(Voluminous details available, if knew
the preferred way to transfer them.)</font><br><br><font size=2 face="sans-serif">Thanks,<br>Mike</font><br><br><BR>