Open Stack

Hi,

I progressed in investigating the bug. I forgot to mention I was 
following "Provided Router/single tenancy" setup.
So, at reboot, my tap/qg/qr network interfaces were down :
7: qg-c39e5df4-7f: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
     link/ether fe:10:8c:d8:d8:ca brd ff:ff:ff:ff:ff:ff
     inet 192.168.10.1/16 brd 192.168.255.255 scope global qg-c39e5df4-7f
     inet 192.168.10.2/32 brd 192.168.10.2 scope global qg-c39e5df4-7f
8: qr-f76e4668-fa: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
     link/ether 52:93:35:8b:11:ff brd ff:ff:ff:ff:ff:ff
     inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-f76e4668-fa
9: tap2ed3cd8a-03: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
     link/ether 0e:3e:e0:61:5e:b0 brd ff:ff:ff:ff:ff:ff
     inet 10.0.0.2/24 brd 10.0.0.255 scope global tap2ed3cd8a-03

So, a short 'ip link set <dev> up' for the three above fixed my issue. 
Other terms, GRE tunneling is fine at reboot, only interface status is 
wrong.
Do you have any idea how to fix it ? I can't issue a 'post-up' statement 
in /etc/network/interfaces and /etc/rc.local is quite a ugly patch I think.

Thanks,
-Sylvain



Le 18/02/2013 18:06, Sylvain Bauza a écrit :
> Hi,
>
> I'll try to be clear. I do follow a classic setup for Quantum with 2 
> NICs and a GRE tunnel in between nodes with br-int/br-tun.
>
> Everything is fine at first install, but when rebooting the network 
> node (including quantum-ovs-plugin-agent, quantum-l3-agent and 
> quantum-dhcp-agent), I notice that DHCP assignation is failing for my 
> VMs.
> A tcpdump shows at physical level that GRE packets are arriving on 
> eth0 (mgmt NIC) on network node (for DHCP request) but no reply is 
> done by the network node.
>
> The workaround I found is to delete br-int and br-tun on network node, 
> create only br-int and restart both services 
> (quantum-{ovs-plugin,l3,dhcp} ) to get things done.
>
> This is quite brutal. Do you know if it's a known bug, or something 
> bad with my setup ?
>
> Thanks,
> -Sylvain