openstack team mailing list archive

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

Damnit, sent before reading.

To delete the SNAT rule in the last part of my message, I'm running the
following in root's crontab
* * * * * /sbin/iptables -t nat --flush nova-network-snat

I'm going to dig into the python to stop it from setting it in the first
place, but I haven't had the time yet. The rules get re-added every time
you change the openstack config, by adding a virt, or editing any of the
security groups etc.

 -- joe.



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

> 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
>>>
>>
>>
>