openstack team mailing list archive

[Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>]

Yet no reply ?

I did the hack, I removed the 169.254.0.0/16 route from my images, but 
this is quite a ugly hack.
Could someone with OpenVswitch/GRE setup please confirm that there is no 
route to create for metadata ?

Thanks,
-Sylvain

Le 21/02/2013 11:33, Sylvain Bauza a écrit :
> Anyone ?
> I found the reason why a 'quantum-dhcp-agent restart' is fixing the 
> route, this is because the lease is DHCPNACK'd at next client refresh 
> and the VM is getting a fresh new configuration excluding 
> 169.254.0.0/16 route.
>
> Community, I beg you to confirm the 169.254.0.0/16 route should *not* 
> be pushed to VMs, and 169.254.169.254/32 should be sent thru the 
> default route (ie. provider router internal IP).
> If it's the case, I'll update all my images to remove that route. If 
> not, something is wrong with my Quantum setup that I should fix.
>
> Thanks,
> -Sylvain
>
> Le 20/02/2013 15:55, Sylvain Bauza a écrit :
> > Hi,
> >
> > Previously using nova-network, all my VMs were having :
> >  # route -n
> > Table de routage IP du noyau
> > Destination     Passerelle      Genmask         Indic Metric Ref Use 
> > Iface
> > 10.0.0.0        0.0.0.0         255.255.255.0   U     0 0 0 eth0
> > 169.254.0.0     0.0.0.0         255.255.0.0     U     1002 0        0 
> > eth0
> > 0.0.0.0         10.0.0.1        0.0.0.0         UG    0 0 0 eth0
> >
> > Now, this setup seems incorrect with Quantum, as the ARP query goes 
> > directly from the network node trying to resolve 169.254.169.254 :
> > [root@toto ~]# curl http://169.254.169.254/
> > curl: (7) couldn't connect to host
> >
> > sylvain@folsom02:~$ sudo tcpdump -i qr-f76e4668-fa -nn not ip6 and 
> > not udp and host 169.254.169.254 -e
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> > decode
> > listening on qr-f76e4668-fa, link-type EN10MB (Ethernet), capture 
> > size 65535 bytes
> > 15:47:46.009548 fa:16:3e:bf:0b:f6 > ff:ff:ff:ff:ff:ff, ethertype ARP 
> > (0x0806), length 42: Request who-has 169.254.169.254 tell 10.0.0.5, 
> > length 28
> > 15:47:47.009076 fa:16:3e:bf:0b:f6 > ff:ff:ff:ff:ff:ff, ethertype ARP 
> > (0x0806), length 42: Request who-has 169.254.169.254 tell 10.0.0.5, 
> > length 28
> >
> > The only way for me to fix it is to remove the 169.254.0.0/16 route 
> > on the VM (or for some reason I doesn't understand, by restarting 
> > quantum-dhcp-agent on the network node) and then L3 routing is 
> > working correctly :
> >
> > [root@toto ~]# route del -net 169.254.0.0/16
> > [root@toto ~]# curl http://169.254.169.254/
> > 1.0
> > 2007-01-19
> > 2007-03-01
> > 2007-08-29
> > 2007-10-10
> > 2007-12-15
> > 2008-02-01
> > 2008-09-01
> > 2009-04-04
> >
> > sylvain@folsom02:~$ sudo tcpdump -i qg-f2397006-20 -nn not ip6 and 
> > not udp and host 10.0.0.5 and not port 22 -e
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> > decode
> > listening on qg-f2397006-20, link-type EN10MB (Ethernet), capture 
> > size 65535 bytes
> > 15:52:58.479234 fa:16:3e:e1:95:20 > e0:46:9a:2c:f4:7d, ethertype IPv4 
> > (0x0800), length 74: 10.0.0.5.55428 > 192.168.1.71.8775: Flags [S], 
> > seq 3032859044, win 14600, options [mss 1460,sackOK,TS val 2548891 
> > ecr 0,nop,wscale 5], length 0
> > 15:52:58.480987 e0:46:9a:2c:f4:7d > fa:16:3e:e1:95:20, ethertype IPv4 
> > (0x0800), length 74: 192.168.1.71.8775 > 10.0.0.5.55428: Flags [S.], 
> > seq 3888257357, ack 3032859045, win 14480, options [mss 
> > 1460,sackOK,TS val 16404712 ecr 2548891,nop,wscale 7], length 0
> > 15:52:58.482211 fa:16:3e:e1:95:20 > e0:46:9a:2c:f4:7d, ethertype IPv4 
> > (0x0800), length 66: 10.0.0.5.55428 > 192.168.1.71.8775: Flags [.], 
> > ack 1, win 457, options [nop,nop,TS val 2548895 ecr 16404712], length 0
> >
> >
> > I can't understand what's wrong with my setup. Could you help me ? I 
> > would have to undergo a post-up statement for all my images... :(
> >
> > Thanks,
> > -Sylvain