openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #20125
Re: Total Network Confusion
Jay, Guys,
The Vlan Manager stuff looks spot on for my needs but I am a tad confused.
(Perhaps Folsom addresses these; I'm just on a deadline to get a PoC running and I don't want to look like I've been wasting time building this).
Assuming I configure my vlan on my switch, set my switchport to trunk and use vlanmanager do Scenarios 6 and 7 extend out to hosts *not* on OpenStack/ not configured via OpenStack?
Would I be able to, say, connect from my PC vlan to one of the vlans configured via OpenStack? Would this also allow me to configure bridges on Open Stack to route via their own IPs and Vlans?
Thanks,
James
On 14 Jan 2013, at 18:11, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> I'd recommend Folsom over Essex :) And I'd highly recommend these
> articles from Mirantis which really step through the networking setup in
> VLANManager. Read through them in the following order and I promise at
> the end you will have a much better understanding of networking in Nova.
>
> http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/
> http://www.mirantis.com/blog/openstack-networking-single-host-flatdhcpmanager/
> http://www.mirantis.com/blog/openstack-networking-vlanmanager/
> http://www.mirantis.com/blog/vlanmanager-network-flow-analysis/
>
> All the best,
> -jay
>
> On 01/14/2013 11:52 AM, James Condron wrote:
>> Hi all,
>>
>> I've recently started playing with (and working with) OpenStack with a
>> view to migrate our production infrastructure from esx 4 to Essex.
>>
>> My issue, or at least utter idiocy, is in the network configuration.
>> Basically I can't work out whether in the configuration of OpenStack I
>> have done something daft, on the network something daft or I've not
>> understood the technology properly.
>>
>> *NB: *I can get to the outside world form my VMs; I don't want to
>> confuse things further.
>>
>> As attached is a diagram I knocked up to hopefully make this simpler,
>> though I hope I can explain it simply with:
>>
>> *************
>> *Given both public and private interfaces on my server being on the same
>> network and infrastructure how would one go about accessing VMs via
>> their internal IP and not have to worry about a VPN or Public IPs?*
>> *************
>>
>> My corporate network works on simple vlans; I have a vlan for my
>> production boxen, one for development, one for PCs, telephony, etc. etc.
>> These are pretty standard.
>>
>> The public, eth0 NIC on my compute node (Single node setup, nothing
>> overly fancy; pretty vanilla) is on my production vlan and everything is
>> accessible.
>> the second nic, eth1, is supposedly on a vlan for this specific purpose.
>>
>> I am hoping to be able to access these internal IPs on their... Internal
>> IPs (For want of a better phrase). Is this possible? I'm reasonably
>> confident this isn't a routing issue as I can ping the eth1 IP from the
>> switch:
>>
>> #ping 10.12.0.1
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 10.12.0.1, timeout is 2 seconds:
>> !!!!!
>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
>>
>> But none of the ones assigned to VMs:
>>
>> #ping 10.12.0.4
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 10.12.0.4, timeout is 2 seconds:
>> .....
>> Success rate is 0 percent (0/5)
>>
>> Or.... for those looking at the attached diagram: vlan101 is great and
>> works fine; what do I need to do (If at all possible) to get vlan102
>> listening?
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Follow ups
References