[Openstack-operators] Correct me if im wrong ... playing around with networkmodes

Leandro Reox leandro.reox at gmail.com
Wed Jun 1 22:24:55 UTC 2011


Hi list, im playing around with network modes and trying to understand
deeply the way that them operate so , i have a couple of questions ...


- In FlatDHCP mode, the network node always sets up the x.x.x.1 ip for
itself to declare itself as the default gw for the instances that we're
going to spaw, if we can to change the ip that assigs to the br100 we can
edit directly the network database, so, the question is : "Is the network
node, always the default gateway for the instances in flatDCHP node ?" , why
im i asking this ? Cause we have over 1000 virtual machines running on other
platform, with a lot of traffic and concurrent conections and having an
"openstack network node" as a default gateway for all this traffic, doest
really scale, at all ... , so i was wondering , the only way to give an
instance an ip, and set up a default gateway that doesnt "resides" on the
network mode, is only in FlatManager mode ?

- In FlatManager , and FlatDHCP mode, in a multiple nodes environment, where
controller and network node are the same, and we have multiple "computes"
nodes, is there a way that we can have a routeable range (in our network
like) 172.16.100.x configured to access the physical machines, and the SAME
range (but subnetted) to inject to the spawning VM instances ? . To be
clear, if my network/controller physical node has the 172.16.100.10 , and
the compute node 172.16.100.11, can i assign 172.16.100.12 and so on the
spawning virtual machines ? I guess this could be end on a routing issue ?

I read that in any cases the network node doenst act as a default gateway
for the outgoing traffic ... but it seems like it is , can anyone clarify
this to me ?


Best regards !


Lele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110601/be0b74a6/attachment-0002.html>


More information about the Openstack-operators mailing list