openstack team mailing list archive

[Joe Warren-Meeks <joe.warren.meeks@xxxxxxxxx>]

Just as an addendum, now that I've got it working, it works really well!


On 15 January 2013 16:43, Joe Warren-Meeks <joe.warren.meeks@xxxxxxxxx>wrote:

> Hey James,
>
> I had exactly your requirement too, and it took me many weeks to get to a
> solution. Hopefully, you won't have to. I have installed and reinstalled it
> so, so many times. For a while I thought I'd lost the ability to
> *computer*. Feel free to contact me offlist if you need any other guidance,
> I'd be very happy to help.
>
> Firstly, if you can use a different NIC for the bridges, I'd strongly
> recommend it.
>
> You need to configure nova to work as multi_host, this will enable you to
> dish out your switch/router IP as the default route via dnsmasq. You also
> need to lightly hack linux_net.py so that this works.
>
> You also need to slighly hack Iptables to stop it SNATting your instances
> out.
>
> Follow
> http://cssoss.files.wordpress.com/2012/05/openstackbookv3-0_csscorp2.pdfup to chapter 2.2.7.
>
> Once you've installed all the Nova packages, stop then.
>
> 0. Linux stuff
> ^^^^^^^^^^^^^^
> Before you start, apt-get install vlan and add 8021q to the end of
> /etc/modules
> If you are using an unconfigured interface as the bridge device, add
> /sbin/ifconfig ethX up
> to /etc/rc.local
>
> 1. Linux net
> ^^^^^^^^^^^^
> You need to copy the attached linux_net.py over
> /usr/share/pyshared/nova/network/linux_net.py
> (Do a diff first, so you can see it isn't trojaned :-)
>
> 2. dnsmasq
> ^^^^^^^^^^
> You need to tell dnsmasq to send out a different IP for your router
> tailor the following and put it into /etc/dnsmasq-nova.conf
>
> ================
> #
> # Set the default route for all networks to be the firewall
> #
> dhcp-option=tag:'production',option:router,10.0.31.1
> dhcp-option=tag:'dmz',option:router,10.0.21.1
> dhcp-option=tag:'development',option:router,10.0.41.1
>
> # devsupp
> dhcp-host=fa:16:3e:66:05:c2,10.0.21.7
> =================
>
> You need to change the tag to match the network label you use when you set
> up the network later on.
>
> 3. nova.conf
> ^^^^^^^^^^^^
> I've attached my nova.conf for you. I'll mark the bits you might need to
> change. Search for ### in there.
>
> 4. Continue with the install
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Restart all the Nova services as soon as you have done the 'nova-manage db
> sync'
>
> 5. Create networks
> ^^^^^^^^^^^^^^^^^^
> nova-manage network create --label=production --fixed_range_v4=
> 10.0.31.0/24 --vlan=31 --bridge_interface=eth3 --multi_host=T
> --project_id=79433bbfc2674bf9bff257a5e0f21581
>
> The important bits are the label, which must match dnsmasq-nova.conf, the
> vlan, bridge interface and multi_host=T
>
>
> So, now you should be done. However, Openstack will try to add in a SNAT
> rule to SNAT some outbound traffic. Vish suggested leaving
> --routing_source_ip= in nova.conf set to nothing, but that doesn't work, it
> throws an error when setting up the iptables rules.
>
> Hope that helps!
>
>  -- joe.
>
>
>
> On 15 January 2013 14:31, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
>
>> On 01/15/2013 05:31 AM, James Condron wrote:
>> > 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?
>>
>> Not quite sure, actually. I'm certainly no networking guru, sorry :( I'd
>> imagine you *could* do this, but it would take manually modifying
>> iptables on the individual compute nodes -- which would mess with the
>> nova-network controller on the compute nodes IIUC...
>>
>> -jay
>>
>> > 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
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>