Ask Your Question
1

Asymetric ARP & DHCP issues on GRE tenant net...

asked 2014-01-30 13:11:15 -0500

jproulx gravatar image

updated 2014-01-30 13:31:25 -0500

bootpc and arp requests from instances using GRE tenant networks are not making it onto the physical network, I suspect this is "all broadcast traffic". If IP is configured statically and the arp cache is set (by pinging from the other end, network controller in this case) I can communicate over the link, until the arp cache times out...note that manually setting the arp cache on the instance with arp -s does not work, so probably more than just broadcast flows getting screwed up.

This was perviously woking. Last know to work prior to teh upgrade from Grizzly to Havana at the beginning of January. As this isn't a widely used feature I'm uncertain if it broke during upgrade or sometime just before or just after.

By fiddling with ovs port mirroring I've been able to determine where the packets disappear from my expected path (and verified that packets are visible at these point when traffic is passing). Packets get as far as patch-int in the br-tun but do not appear on the gre-<n> device:

tap                -> patch-tun        -> patch-int     ->   gre-<N>         -> eth0 
(has packets)        (has packets)      (still there)   !!   (no packets)       (no packets)
\_________________________________/     \________________________________/      (GRE wrapped)
             br-int                               br-tun                        IP of tunnel endpoint

How can I fix this? The nodes are in production and most instances use VLAN based provider networks which work fine, so reboot and try again isn't really an option, bu tif there is a way to reset all the virtual networking state I could take a few second network blip if I had to...setup is Ubuntu 12.04 w/ Havana cloud archive packages

edit retag flag offensive close merge delete

Comments

The way this works has changed completely with Havana. For the compute node in question, can you post to paste.openstack.org the entire output of `ovs-ofctl dump-flows br-tun` and `ovs-ofctl show br-tun` and `ovs-vsctl show` and state the ip address of the network node.

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-01-31 05:43:08 -0500 )edit
jproulx gravatar imagejproulx ( 2014-01-31 08:40:39 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-01-31 10:42:53 -0500

darragh-oreilly gravatar image

You are missing the flows for flooding, which should be in table 21. They are added here or modified here. I assume you have l2_population disabled as it is by default? Have any new nodes been added (that would have trigged the mod_flow call) since the agent was last restarted? What plugin are you using OVS or ML2? Does the agent log, system log or ovs logs have anything about adding such flows?

edit flag offensive delete link more

Comments

Ah ha, there are repeated errors about running `ovs-ofctl mod-flows br-tun <timeout=0,idle_timeout=0,priority=1,table=21,dl_vlan=1,actions=strip_vlan,set_tunnel:3,output:4,58,etc>`, if I run failing cmd by hand it errors "ovs-ofctl: unknown keyword hard_timeout", using ovs 1.4 (1.10 fails worse)

jproulx gravatar imagejproulx ( 2014-01-31 11:03:06 -0500 )edit

on the ovs 1.10 system I have no connnectivity at all on GRE. the gre-n ports showup in 'ovs-vsctl list-ports br-tun' but not at all in 'ovs-ofctl show br-tun' teh flow modificatiuon fails there with " -1: negative values not supported for in_port"

jproulx gravatar imagejproulx ( 2014-01-31 11:06:16 -0500 )edit

Can you try this: "sudo ovs-ofctl mod-flows br-tun table=21,priority=1,dl_vlan=1,actions=strip_vlan,set_tunnel:0x3,output:53"

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-01-31 11:29:04 -0500 )edit

ovs-ofctl: unknown keyword priority

jproulx gravatar imagejproulx ( 2014-01-31 11:40:47 -0500 )edit

I googled "ovs-ofctl: unknown keyword priority" and got https://bugs.launchpad.net/neutron/+bug/1221926 . Seems to be a problem with OVS pre 1.10. The problem with your 1.10 system is different - you need to get the kernal module fixed up on it.

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-01-31 11:57:47 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

Stats

Asked: 2014-01-30 13:11:15 -0500

Seen: 691 times

Last updated: Jan 31 '14