<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Dan,<br>
<br>
Thanks for your clear answer. I do confirm, the 169.254.0.0/16
route was working with my nova-network setup (FlatDHCP).<br>
<br>
When mentioning Grizzly pushing a route to VMs, I guess it would
be possible to backport it to Folsom.<br>
Do you have any idea on which changes to do for that feature ?<br>
I'll take a look at dnsmasq and see if I can hardcode this.<br>
<br>
-Sylvain<br>
<br>
Le 26/02/2013 06:37, Dan Wendlandt a écrit :<br>
</div>
<blockquote
cite="mid:CA+0XJm8EtbfSFMF8r0BnYAHQSZppFc0ZfWn4CjDUFx03FvuHCQ@mail.gmail.com"
type="cite">Hi Sylvain,
<div><br>
</div>
<div>The answer here is that "it depends". </div>
<div><br>
</div>
<div>If you are using Folsom + Quantum, the only supported
mechanism is reaching the metadata server is via your default
gateway, so VMs should not have specific routes to reach the
metadata subnet (I believe this is also the case for
nova-network, so I'm a bit surprised by your original comments
in this thread about using the direct route with nova-network).</div>
<div><br>
</div>
<div>In Grizzly, Quantum will support two different mechanisms of
reaching metadata. One via the router (as before) and another
via the DHCP server IP (with a route for <a
moz-do-not-send="true" href="http://169.254.169.254/32">169.254.169.254/32</a>
injected into the VM via DHCP). The latter supports metadata on
networks that do not have a router provided by Quantum.</div>
<div><br>
</div>
<div>Dan<br>
<br>
<div class="gmail_quote">On Mon, Feb 25, 2013 at 8:36 AM,
Sylvain Bauza <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sylvain.bauza@digimind.com" target="_blank">sylvain.bauza@digimind.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Yet no
reply ?<br>
<br>
I did the hack, I removed the <a moz-do-not-send="true"
href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a>
route from my images, but this is quite a ugly hack.<br>
Could someone with OpenVswitch/GRE setup please confirm that
there is no route to create for metadata ?<br>
<br>
Thanks,<br>
-Sylvain<br>
<br>
Le 21/02/2013 11:33, Sylvain Bauza a écrit :
<div class="HOEnZb">
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyone ?<br>
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 <a
moz-do-not-send="true" href="http://169.254.0.0/16"
target="_blank">169.254.0.0/16</a> route.<br>
<br>
Community, I beg you to confirm the <a
moz-do-not-send="true" href="http://169.254.0.0/16"
target="_blank">169.254.0.0/16</a> route should
*not* be pushed to VMs, and <a moz-do-not-send="true"
href="http://169.254.169.254/32" target="_blank">169.254.169.254/32</a>
should be sent thru the default route (ie. provider
router internal IP).<br>
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.<br>
<br>
Thanks,<br>
-Sylvain<br>
<br>
Le 20/02/2013 15:55, Sylvain Bauza a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Previously using nova-network, all my VMs were
having :<br>
# route -n<br>
Table de routage IP du noyau<br>
Destination Passerelle Genmask
Indic Metric Ref Use Iface<br>
10.0.0.0 0.0.0.0 255.255.255.0 U
0 0 0 eth0<br>
169.254.0.0 0.0.0.0 255.255.0.0 U
1002 0 0 eth0<br>
0.0.0.0 10.0.0.1 0.0.0.0 UG
0 0 0 eth0<br>
<br>
Now, this setup seems incorrect with Quantum, as the
ARP query goes directly from the network node trying
to resolve 169.254.169.254 :<br>
[root@toto ~]# curl <a moz-do-not-send="true"
href="http://169.254.169.254/" target="_blank">http://169.254.169.254/</a><br>
curl: (7) couldn't connect to host<br>
<br>
sylvain@folsom02:~$ sudo tcpdump -i qr-f76e4668-fa
-nn not ip6 and not udp and host 169.254.169.254 -e<br>
tcpdump: verbose output suppressed, use -v or -vv
for full protocol decode<br>
listening on qr-f76e4668-fa, link-type EN10MB
(Ethernet), capture size 65535 bytes<br>
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<br>
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<br>
<br>
The only way for me to fix it is to remove the <a
moz-do-not-send="true"
href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a>
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 :<br>
<br>
[root@toto ~]# route del -net <a
moz-do-not-send="true"
href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a><br>
[root@toto ~]# curl <a moz-do-not-send="true"
href="http://169.254.169.254/" target="_blank">http://169.254.169.254/</a><br>
1.0<br>
2007-01-19<br>
2007-03-01<br>
2007-08-29<br>
2007-10-10<br>
2007-12-15<br>
2008-02-01<br>
2008-09-01<br>
2009-04-04<br>
<br>
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<br>
tcpdump: verbose output suppressed, use -v or -vv
for full protocol decode<br>
listening on qg-f2397006-20, link-type EN10MB
(Ethernet), capture size 65535 bytes<br>
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<br>
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<br>
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<br>
<br>
<br>
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... :(<br>
<br>
Thanks,<br>
-Sylvain<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net"
target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp"
target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt
<div>Nicira, Inc: <a moz-do-not-send="true"
href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>