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.ba...@digimind.com <mailto:sylvain.ba...@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@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@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@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@os-network:~#


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to