Open Stack

We're using quagga for route exchange (via ospf) between the network
servers, and the api server. The api server peers with each network
server. This is about as simple a quagga setup as you can have.
Basically, when nova-network starts up a new project network, quagga
begins to advertise that network into ospf. The api server sees that
advertisement and can use that to reach the node (for metadata
requests).

Incidentally, you might want to lock down your POSTROUTING rule to
ensure that vms can't hit your management network. IIRC, we were able
to use a similar rule, except with a specific host and port as opposed
to a blanket rule for the whole network.
 -nld

2011/5/10 郭耀謙 <tonytkdk at gmail.com>:
> #iptables -t nat -A  nova-network-POSTROUTING -s 10.0.0.0/12 -d
> 192.168.1.0/24 -j ACCEPT
> That's what I did on nova-network host .
> btw , I always isolate nova-network.
> I'm interesting about quagga in your environment.
>
> 2011/5/11 Narayan Desai <narayan.desai at gmail.com>
>>
>> For what it's worth, we're running in a configuration similar to the
>> one in the attached diagram using VlanManager. When we moved the
>> nova-network service off of the machine with nova-api, we needed to
>> add an additional prerouting rule on the network server that prevented
>> the traffic from being sent out via NAT (which caused the source
>> address to be lost, resulting in a metadata resolution error). Once
>> the packets arrive at the api service with the correct source address,
>> they need a route back, via the nova-network server in order to get
>> the response packets onto the correct vlan. With a single nova-network
>> server, a static route will do. With multiple nova-network instances
>> on different systems, things get a little more complicated. We ended
>> up setting up route distribution via quagga between the nova-api
>> server, and the nova-network servers. This ensures that nova-api knows
>> which nova-network instance to use to reach any particular project
>> network.
>>  -nld
>>
>> On Tue, May 10, 2011 at 9:08 PM, 郭耀謙 <tonytkdk at gmail.com> wrote:
>> > Hello , guys
>> > There's a problem while separate instance's network and nova-management
>> > network.
>> > EX.
>> > Nova management network : 192.168.1.0/24  eth0
>> > Instance network               :  10.0.0.0/12      eth1 bridge to br100
>> > During cloud-setup :
>> > Instance try to retrieve metadata from 169.254.169.254.
>> > Instances(10.0.0.0/12) request 169.254.169.254 PREROUTING from
>> > gateway(nova-network).
>> > But If PREROUTING rule is already been set on nova-Compute node,
>> > instance
>> > request will be redirected on VM host instead of nova-network host.
>> > So If your topology is like A diadram from StackOps , Plz Check iptables
>> > rule on Compute nodes.
>> > -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT
>> > --to-destination 192.168.1.2:8773
>> > And del this rule , your instance will get metadata correctly....
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack at lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>