Please contact your support team if you have a question or need assistance for any Rackspace products, services, or articles.
This question is answered.
The goal is route traffic from one subnet to another using a computer in the middle with two NIC's. I have successfully created the scenario on both my own computer with VirtualBox and on the cloud with Rackspace's trail cloud. The images I am using for our private cloud and virtualbox are identical and rackspace had the same version of os, just not identical.
When trying the same setup our private cloud, the middle instance is able to ping machines on both subnets. The machines on separate sunsets are able to ping the NIC on the same subnet for the middle instance, but fail when trying to ping the NIC on the other subnet. Running TCP dump on the machines, I can see that the NIC on the different subnet receives the pings and sends a response. But that response never makes it back and I can't find out where it is going. None of the NICs show any dropped packets and I have turned off all the Filtering and Firewalls that i know of that could be messing with the pings.
I'm leaning towards this having to do with Neutron and Open vSwitch. I wouldn't call it an issue or misconfiguration because what you are trying to do is always handled by a Neutron Router and not an OpenStack Instance. There is probably some lower level configuration happening on the Neutron Router that has not yet been applied to the OpenStack Instance you are trying to use a router.
The Rackspace Public Cloud uses Neutron but it does not use Open vSwitch as a backend.
An instance can be configured to act as a router between two subnets, but the following would need to be observed:
- ipv4 forwarding would need to be be enabled in the router instance
- iptables rules would need to be created for the router instance that allow for addresses/subnets other than the one owned by the instance to be forwarded. This means that the 'allowed-address-pairs' extention would be utilized to define multiple source addresses/subnets. This can be invoked using the Neutron port-update command for the router instance's ports. One update would allow net2's subnet on the net1 interface, and vice-versa. Neutron will update the iptables on the respective compute node.
If router R is a Neutron router, then something else is wrong.
If I'm off-base here please let me know and we can go into further detail as to what you're trying to accomplish.
James D.Network EngineerRackspace Private Cloud
When you say "our private cloud", do you mean Rackspace Private Cloud powered by OpenStack? If yes, what version are you running?
Rackspace Private Cloud running Openstack with nova --version = 2.15.0
When you say "middle instance" do you mean a physical machine?
(edit: scratch my last suggestion)
That's the version of OpenStack Nova Python Client, not the version of Rackspace Private Cloud. When you install Rackspace Private Cloud, you have to checkout a particular git branch/tag. Do you remember what branch/tag you checked out? That branch/tag will tell me what version of RPC you are working with.
Also, have you enabled IPv4 Forwarding on the "middle machine"? It can be enabled with the following commands:
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -w net.ipv4.ip_forward=1
Try 'knife cookbook list' on the controller. The RPC version number should be able to be found this way.
Please provide the full output, and we will parse through it.
no, all are instances inside of openstack on the same network but different subnets
nic2 = 10.40.43.11
vm3 nic= 10.40.43.12
Don't remember off the top of my head but will edit this commet when I find it. Yes ip forwarding is on.
WARNING: No knife configuration file foundERROR: ArgumentError: Cannot sign the request without a client name, check that :node_name is assigned
I know I am on Havana....edit(4.2.2)
First, what sort of networks are the OpenStack Instances attached to? Are they connected to Neutron Tenant Networks (or in other words, software defined networks)? If they are, then why not use a Neutron Router instead of this "middle machine"?.
Second, why are you using another OpenStack Instance as a router?
Yes they are neutron networks. This is research work and the scenario calls for instance to route through instances not routers, so thats how it has to be set up.
What steps did you do on your computer and VirtualBox that successfully worked but are not working within RPC?
I did the exact same thing in all three.
stop iptables service (CENTOS)
route vm1 through vm2 ......route add -net 10.40.43.0 netmask 255.255.255.0 gw 10.40.42.11
route vm3 through vm2 ......route add -net 10.40.42.0 netmask 255.255.255.0 gw 10.40.43.11
I was able to replicate your issue. I have not figured out why packets are not being forwarded properly.
When you did the same setup on your laptop with VirtualBox, where you just using regular virtual machines, or where you using DevStack or some other OpenStack related thing?
Also, you said this same setup worked on the "Rackspace's trail cloud". Can you clarify what that is? Do you mean the Rackspace Public Cloud?
Regular Virtual box. Yes I mean Rackspace Public Cloud.
Interesting that you were able to replicate it. I had hoping it was just a misconfiguration on my end but with you replicating the issue that becomes less likely. If it worked on the public cloud then maybe it uses a different implementation then what we are using?
thanks for help
The Rackspace Community (“Community”) is provided “AS IS” without warranty of any kind. The information on the Community sites is created by members of the Community and is intended for reference and general discussions only. Although some of the content may contain information provided by Rackspace employees, it does not represent an assessment of a particular customer environment or an assessment of any specific compliance with laws or regulations or constitute advice. We recommend that you engage additional expertise in order to further evaluate applicable requirements for your specific environment. For customer specific support issues please contact your Rackspace Support Team.READ MORE
RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THE RACKSPACE OPEN CLOUD COMMUNITY SITE. RACKSPACE RESERVES THE RIGHT TO DISCONTINUE OR MAKE CHANGES TO ITS SERVICES OFFERINGS AND SPECIFICATIONS AT ANY TIME WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF ANY SERVICES AND/OR PROCESSES MENTIONED IN ANY COMMUNITY DISCUSSIONS. EXCEPT AS SET FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS, CLOUD TERMS OF SERVICE AND/OR OTHER AGREEMENT YOU SIGN WITH RACKSPACE, RACKSPACE ASSUMES NO LIABILITY WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO ITS SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.
ALTHOUGH PART OF THE COMMUNITY GENERATED CONTENT MAY EXPLAIN HOW RACKSPACE SERVICES MAY WORK WITH THIRD PARTY PRODUCTS, THE INFORMATION CONTAINED IN THE COMMUNITY DISCUSSIONS IS NOT DESIGNED TO WORK WITH ALL SCENARIOS. ANY USE OR CHANGES TO THIRD PARTY PRODUCTS AND/OR CONFIGURATIONS SHOULD BE MADE AT THE DISCRETION OF YOUR ADMINISTRATORS AND SUBJECT TO THE APPLICABLE TERMS AND CONDITIONS OF SUCH THIRD PARTY. EVEN THOUGH RACKSPACE EMPLOYEES MAY PARTICIPATE IN THE COMMUNITY DISCUSSIONS, RACKSPACE DOES NOT PROVIDE TECHNICAL SUPPORT FOR THIRD PARTY PRODUCTS, OTHER THAN SPECIFIED IN YOUR HOSTING SERVICES AGREEMENT YOU HAVE SIGNED WITH RACKSPACE AND RACKSPACE ACCEPTS NO RESPONSIBILITY FOR THIRD-PARTY PRODUCTS.READ LESS