openstack team mailing list archive

[Greg Chavez <greg.chavez@xxxxxxxxx>]

Well, the subject is "A Grizzly apring failure".  So I'm using Grizzly
:)  Sorry, bad joke.  I have a multi-node setup on Raring, with a
3-nic network node (public, management, vm config nets) using OVS and
GRE encapsulation.  It looks like this:

http://chavezy.files.wordpress.com/2013/03/ostack-log-net_iscsi.png

It's clear to me that the arp fails on the tenant-network-side of the
quantum router.  If you look at my original message, you see that the
arp requests for the tenant IP go unanswered by dnsmasq (I assume?).
So whatever's wrong, it *seems* like it's in the tenant namespace on
the network node.

Now is an interesting time, though, because I can ping all the VMs I
have up from the external network.  But notice the latency of the
first ping packet:

PING 10.21.166.2 (10.21.166.2) 56(84) bytes of data.
64 bytes from 10.21.166.2: icmp_seq=1 ttl=63 time=1001 ms
64 bytes from 10.21.166.2: icmp_seq=2 ttl=63 time=1.95 ms
64 bytes from 10.21.166.2: icmp_seq=3 ttl=63 time=0.646 ms
64 bytes from 10.21.166.2: icmp_seq=4 ttl=63 time=0.901 ms

That's a full second!  My developers won't stand for that.  My
suspicion is that something is amiss with the tenant network's dnsmasq
instance. But I don't know for sure.

PLEASE can somebody help! Darragh, thank you for replying.

On Fri, May 10, 2013 at 3:07 PM, Darragh O'Reilly
<dara2002-openstack@xxxxxxxxx> wrote:
> can you try using -e with tcpdump to see the ethernet headers - it may be
> arps
> from the router to ff:ff:ff:ff:ff:ff that are not getting across in that
> direction. You should continue tcpdumping on the devices along the path to
> the
> instance to see where the arp request (or reply) stops. You do not say which
> plugin you are using? Is it multinode? (if OVS plugin, GRE or VLANs?)
> Grizzly?
>



-- 
\*..+.-
--Greg Chavez
+//..;};