[ovs-discuss] Help with GRE Tunnels
Justin Brown
justin.brown at fandingo.org
Mon Aug 5 17:19:36 UTC 2013
Hello,
With Pravin's help over on the dev list, I got Openvswitch running on
Linux 3.10 over the weekend with the proper kernel module. I'm trying
to use Openvswitch with Openstack Quantum, but I'm having some trouble
with Openvswitch. Openstack seems to set everything up properly, so I
just need some help looking into what's happening in the Openvswitch
black box.
Here's the simple setup that I'm trying to get working before
expanding. There is a Quantum server that has a static IP of
192.168.26.10/24. There is a compute node that has a static IP of
192.168.26.20/24. The communication between these nodes works fine.
Openstack has setup a private network at 10.0.1.0/24 and is supposed
to have a DHCP server listening on a tap device tap4f517c5d-c3 at
10.0.1.3. Note that the ovs port for this tap device is automatically
created by Openstack, but the Linux interface is not. For
troubleshooting, I did `tunctl -t tap4f517c5d-c3 && ip add add
10.0.1.3/24 && ip link set up tap4f517c5d-c3`.
I deployed VM A to the compute node that has IP 10.0.1.2/24. VM A
could not receive a DHCP address, so I manually assigned one. I
deployed a second VM, VM B, to the same compute node and manually
assigned IP 10.0.1.4/24.
VMs A and B can communicate fine, so the internal bridge br-int is
working. However, I cannot communicate with the tap device on the
other server. It seems like br-tun is broken or the patch interface
between br-tun and br-int is not working.
Bascially, from what I can tell, Openstack Quantum is working fine and
without error, and Openvswitch is not throwing any errors, but the GRE
tunnel doesn't seem to be working. I've tried looking at a variety of
tcpdumps on 'net 10.0.1.0/24' on several different interfaces, but I
can't get a handle on how Openvwitch is processing traffic.
Could someone help me figure out if traffic is flowing over the
tunnels, and if not, what needs to be done to fix it?
Thanks,
Justin
Here are my configurations.
Quantum Server:
[root at quantum ~]# ovs-vsctl show
db9d127e-b622-4564-aec9-f817c278cb24
Bridge br-int
Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "tap4f517c5d-c3"
tag: 1
Interface "tap4f517c5d-c3"
type: internal
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, out_key=flow, remote_ip="192.168.26.20"}
ovs_version: "1.10.1"
=================
[root at quantum ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=1663.827s, table=0, n_packets=0, n_bytes=0,
idle_age=1663, priority=3,tun_id=0x1,dl_dst=fa:16:3e:6a:2d:cd
actions=mod_vlan_vid:1,NORMAL
cookie=0x0, duration=1664.499s, table=0, n_packets=6, n_bytes=468,
idle_age=1654, priority=4,in_port=1,dl_vlan=1
actions=set_tunnel:0x1,NORMAL
cookie=0x0, duration=1664.172s, table=0, n_packets=0, n_bytes=0,
idle_age=1664, priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=mod_vlan_vid:1,output:1
cookie=0x0, duration=1855.585s, table=0, n_packets=5, n_bytes=398,
idle_age=1665, priority=1 actions=drop
Note that fa:16:3e:6a:2d:cd doesn't match the MAC of ANY interface
anywhere on my network.
===================
===================
Compute Node:
[root at comput1 ~]# ovs-vsctl show
6584bc8f-ef5b-436f-b54a-63303a1ca6d8
Bridge br-tun
Port "gre-2"
Interface "gre-2"
type: gre
options: {in_key=flow, out_key=flow, remote_ip="192.168.26.10"}
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Bridge br-int
Port "tapcce1b25d-f6"
tag: 1
Interface "tapcce1b25d-f6"
Port "tap2f8e94c4-b5"
tag: 1
Interface "tap2f8e94c4-b5"
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
ovs_version: "1.10.1"
=====================
[root at compute1 ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=1887.08s, table=0, n_packets=0, n_bytes=0,
idle_age=1887, priority=3,tun_id=0x1,dl_dst=fa:16:3e:6c:d6:c4
actions=mod_vlan_vid:1,NORMAL
cookie=0x0, duration=1739.541s, table=0, n_packets=0, n_bytes=0,
idle_age=1739, priority=3,tun_id=0x1,dl_dst=fa:16:3e:00:fe:4e
actions=mod_vlan_vid:1,NORMAL
cookie=0x0, duration=1887.444s, table=0, n_packets=172,
n_bytes=27588, idle_age=133, priority=4,in_port=1,dl_vlan=1
actions=set_tunnel:0x1,NORMAL
cookie=0x0, duration=1887.263s, table=0, n_packets=0, n_bytes=0,
idle_age=1887, priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=mod_vlan_vid:1,output:1
cookie=0x0, duration=3941.552s, table=0, n_packets=2, n_bytes=140,
idle_age=3933, priority=1 actions=drop
These MAC addresses match the NICs on VM A and B.
More information about the discuss
mailing list