"I followed the instructions to add a
route from http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
but I don't immediately see how the route add helped here - but it
has raised an eyebrow."
Tell me about it!
We wanted to use Quantum mostly so we could avoid being forced to
upgrade from nova-network later on. Once again the difference
between trunk (dev) and stable (ops) kills new OpenStack features
for early production adopters. There is no way we can offer this
to our customers. Are we expected to add a new route for every
subnet our customers create, across every compute node, on the fly
(including esoteric quantum port-list commands)?
As for the idea of having one quantum-l3-agent that NATs traffic
for many compute nodes, I wasn't aware the concept of retro chic
applied to network topologies :(
I shudder to think how this would operate at scale, so it looks
like we will be sticking to our nova-network VLAN configuration.
On 08/11/12 22:54, Kevin Jackson wrote:
Hi Stephen,
This is what I get... (note change of namespace etc as this
machine is a VM that was recreated).
root@openstack:~# ip netns list
qdhcp-3f0a3d53-f3a4-4da8-a5e0-1a97b6e51424
qrouter-f26858db-3ae8-431b-86a7-edab80834586
root@openstack:~# ip netns exec
qrouter-f26858db-3ae8-431b-86a7-edab80834586 wget http://172.16.0.210:8775/
--2012-11-08 10:52:11-- http://172.16.0.210:8775/
Connecting to 172.16.0.210:8775... failed: No route to host.
root@openstack:~# ip netns exec
qrouter-f26858db-3ae8-431b-86a7-edab80834586 ip
r
default via 172.16.1.254 dev qg-c396e75e-38
10.5.5.0/24 dev qr-031aafac-19 proto
kernel scope link src 10.5.5.1
172.16.1.0/24 dev qg-c396e75e-38 proto
kernel scope link src 172.16.1.10
So it is a problem between my router and the physical network...
That 172.16.1.0/24 is an "ext-net" network
created with an external router. When I spin my instances up I
use the 10.5.5.0/24 "int-net" network.
I followed the instructions to add a route from http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
but I don't immediately see how the route add helped here - but it
has raised an eyebrow.
The output of the port-list gave me 172.16.1.10 to use as the
$ROUTER_GW_IP - which is odd as that IP was set as my external
floating range start IP. Doing a traceroute to the 172.16.0.201
address from the router namespace went via 172.16.1.10... so I've
some things to play with for the time being...
Thanks for your help so far. Is the Guardian looking at OpenStack
for any projects (I'm from TMG)?
Cheers,
Kev
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
|
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
