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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
