Neutron: VXLAN in Havana
Has anyone been able to successfully run either OVS or ML2 with VXLAN networking and can help me understand what pitfalls I might run into in doing so?
I have a stable/havana cluster that works great with GRE running in both OVS and ML2 (I've since switch to ML2, chasing issues in a deprecated plugin just seems like a fool's endeavour :-)
I'm devstack based and basically follow the directions on the ML2 wiki
I see the usual br-tun, br-int, and associated vxlan port on both controller and compute node, e.g.,
sudo ovs-vsctl show
a426636d-4a2d-4a25-bc5b-8945409e1cab
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "vxlan-192.168.3.3"
Interface "vxlan-192.168.3.3"
type: vxlan
options: {in_key=flow, local_ip="192.168.3.2", out_key=flow, remote_ip="192.168.3.3"}
Port br-tun
Interface br-tun
type: internal
Bridge br-int
Port "qvob86969c3-c8"
tag: 1
Interface "qvob86969c3-c8"
Port "qvo9da1c5b9-44"
tag: 1
Interface "qvo9da1c5b9-44"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
Port "qvo9c11361a-7f"
tag: 1
Interface "qvo9c11361a-7f"
Port "qvo483db35f-ca"
tag: 1
Interface "qvo483db35f-ca"
ovs_version: "1.10.2"
This mirrors what I would see for GRE (which works) except of course the interface type on the tunnel port would be "gre". As you can see, I'm using OVS 1.10.2 which has VXLAN support (bigger picture is I am based on Ubuntu 13.10 saucy which supplies that version of OVS).
I can fire up VMs and see VMs on the compute node try to get dhcp via the console log and fail, and I also see vxlan encapsulated packets arriving on the controller from the compute node during the process. I thought maybe there might be an MTU issue after poking around on google for discussions of VXLAN and openvswitch/ml2/neutron, but inspecting interfaces (both ovs and physical) I see no indication of packet drops (at least, no reports if packet loss using ipconfig or ovs-dpctl) on either the compute or controller node (and I am guessing if MTU were an issue, I'd be seeing packet drops (right?)).
I'm still getting my feet wet with VXLAN and I'm also still learning about Linux networking, but have for the better part of the year had little problem with GRE in folsom, grizzly, and (now) havana, so thinking I'm just missing something that may be obvious to others regarding VXLAN - clearly just telling ML2 that I want to use VXLAN isn't sufficient.
ovs-vsctl from the controller:
5ee4d85c-f0c9-4ccc-be1a-a4ea685c1c8e
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "qvoc7ea9e28-d8"
tag: 1
Interface "qvoc7ea9e28-d8"
Port "qvoe6f6e5fa-31"
tag: 1
Interface "qvoe6f6e5fa-31"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qvo24371d66-7a"
tag: 1
Interface "qvo24371d66-7a"
Port "qvoe9f82b47-b3"
tag: 1
Interface "qvoe9f82b47-b3"
Port "tapbbdf3a9d-c9"
tag: 1
Interface "tapbbdf3a9d-c9"
type: internal
Bridge br-tun
Port "vxlan-192.168.3.2"
Interface "vxlan-192.168.3.2"
type: vxlan
options: {in_key=flow, local_ip="192.168.3.3", out_key=flow, remote_ip="192.168 ...
