Open Stack

Your route is correct, 10.5.5.0/24 is resolved thru qr-XXXX by default.
I haven't had time to look at tcpdumps carefully, but it seems your 
network node is receiving the ARP query and replying.
I would suggest to monitor all interfaces on both compute node and 
network node using the tcpdump '-i any' flag to make sure both ARP 
request and reply are correctly routed.

If by assigning IP addresses to the VMs, you can see traffic coming back 
and forth the GRE tunnels, I would say the L2 agents are working 
correctly. If this is only a DHCP lease issue, I would try to 
delete/recreate br-int and restart all quantum-*-agents on the network node.

Sorry, can't help further :-(

-Sylvain

Le 06/03/2013 18:45, The King in Yellow a écrit :
>
> On Wed, Mar 6, 2013 at 10:15 AM, Sylvain Bauza 
> <sylvain.bauza at digimind.com <mailto:sylvain.bauza at digimind.com>> wrote:
>
>     Le 05/03/2013 18:14, The King in Yellow a écrit :
>
>
>
>         I'm not clear on what the interfaces are, but q-9f9041ce-65 is
>         10.5.5.1 on the network node, so he seems to be seeing the
>         traffic.  tap45ffdc5f-da is listed as 10.5.5.2, and I have no
>         idea what function that is performing.
>
>
>
>     qr-XXXXX is the internal router IP interface (as you correctly
>     guessed, ie. 10.5.5.1) and bound to br-int.
>     tap-XXXX is the DHCP server IP interface (ie. 10.5.5.2), also
>     bound to br-int.
>
>     'brctl show' gives you the output.
>
>     Could you please provide us "route -n" on the network node" ?
>
>
> os at os-network:~$ route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
> 0.0.0.0         10.42.36.1      0.0.0.0         UG 0      0        0 
> qg-28108125-11
> 0.0.0.0         10.42.38.1      0.0.0.0         UG 0      0        0 eth3
> 10.5.5.0        0.0.0.0         255.255.255.0   U 0      0        0 
> tap45ffdc5f-da
> 10.5.5.0        0.0.0.0         255.255.255.0   U 0      0        0 
> qr-9f9041ce-65
> 10.10.10.0      0.0.0.0         255.255.255.0   U 0      0        0 eth1
> 10.42.36.0      0.0.0.0         255.255.254.0   U 0      0        0 
> qg-28108125-11
> 10.42.38.0      0.0.0.0         255.255.254.0   U 1      0        0 eth3
> 169.254.0.0     0.0.0.0         255.255.0.0     U 1000   0        0 eth0
> 192.168.0.0     0.0.0.0         255.255.255.0   U 0      0        0 eth0
> os at os-network:~$
>
>     Could you also make sure (with 'ovs-vsctl show') that port
>     'qr-XXXX' and 'tapXXXX' do have the same tag number as for VMs ?
>     (should be tag:1)
>
>
> They are:
>
> root at os-network:~# ovs-vsctl show
> e232f8c8-1cb8-4cf5-9de5-49f41e59fd38
>     Bridge br-tun
>         Port br-tun
>             Interface br-tun
>                 type: internal
>         Port patch-int
>             Interface patch-int
>                 type: patch
>                 options: {peer=patch-tun}
>         Port "gre-2"
>             Interface "gre-2"
>                 type: gre
>                 options: {in_key=flow, out_key=flow, 
> remote_ip="10.10.10.2"}
>     Bridge br-int
>         Port br-int
>             Interface br-int
>                 type: internal
>         Port patch-tun
>             Interface patch-tun
>                 type: patch
>                 options: {peer=patch-int}
>         Port "qr-9f9041ce-65"
>             tag: 1
>             Interface "qr-9f9041ce-65"
>                 type: internal
>         Port "tap45ffdc5f-da"
>             tag: 1
>             Interface "tap45ffdc5f-da"
>                 type: internal
>     Bridge br-ex
>         Port "qg-28108125-11"
>             Interface "qg-28108125-11"
>                 type: internal
>         Port "eth2"
>             Interface "eth2"
>         Port br-ex
>             Interface br-ex
>                 type: internal
>     ovs_version: "1.4.0+build0"
> root at os-network:~#
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130307/41cb0e57/attachment.html>