Open Stack

Tue May 21 00:56:34 UTC 2013

Steven:

The first thing that jumps out at me is that your physical eth0 interface is attached to a bridge (br-eth0), and eth0 also has an IP address (172.16.32.12), and that IP address is on the subnet of your default gateway (172.16.32.1).

> default via 172.16.32.1 dev eth0  metric 100 
> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 00:15:17:15:ac:78 brd ff:ff:ff:ff:ff:ff
>     inet 172.16.32.12/24 brd 172.16.32.255 scope global eth0
>     inet6 fe80::215:17ff:fe15:ac78/64 scope link 
>        valid_lft forever preferred_lft forever
> 14: phy-br-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 82:d5:6e:2a:bd:87 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::80d5:6eff:fe2a:bd87/64 scope link 
>        valid_lft forever preferred_lft forever
> 
> bridge name bridge id STP enabled interfaces
> br-eth0 0000.00151715ac78 no eth0

Because of how Linux is implemented, if you attach an interface to a bridge, then you can't put an IP address on the interface; you must remove the IP address from the interface and attach it to the bridge instead. For details, see the first question under the heading "Configuration Problems" in the Open vSwitch FAQ <http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD>. (Note: the same issue exists for Linux bridges).

If your setup supports having a separate management network and data network (see http://docs.openstack.org/grizzly/openstack-network/admin/content/connectivity.html), I recommend using a router on your management network as your default gateway. In your case, it looks like you have a separate network on eth2, so if you change your default route to a router on your 192.168.0.0/24 network, it may clear up your problem.

In general, your compute node doesn't need to have an IP address on the data network. If you want it to have one, add it to one of the bridges rather than directly to eth0.

Hopefully, this will resolve your issue.

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com

On May 20, 2013, at 6:58 PM, Steven Barnabas <sbarnabas at frontporch.com> wrote:

> Ok, I'm pretty sure it has something to do with my compute box.  everything else works.  I can ping out from my network box but I can't ping anything from my compute box or VM.  When I do a TCP dump on my Compute box and try to ping it from my network box, I can see the requests coming in but the compute box never sends a response back to the ICMP.  Im not sure whats going on.
> 
> 
> Steven Barnabas
> Network Engineer 
> Front Porch, Inc.
> 209-288-5580
> 209-652-7733 mobile
> www.frontporch.com
> 
> 
> 
> On May 20, 2013, at 3:19 PM, Steven Barnabas <sbarnabas at frontporch.com>
>  wrote:
> 
>> I have had to re-build my Compute box because I could was not able to get to the internet anymore through my VM once I had created the new network.  So now I am back to trying to get my flat network up and running with my VM.  For some reason, I cannot ping anything from my compute box other than the management IP's.  I followed the instructions on creating a flat network as before but this time its not working.  
>> 
>> the only thing I did different this time was in /etc/sysctl.conf  I changed ipv4 ip _forward = 0 to 1.  But this did not help.   I am going to change it back.
>> 
>> Here is the information you requested.  This is from my compute box.
>> 
>> ip a:
>> root at FPCompute:~# ip a
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>     inet 127.0.0.1/8 scope host lo
>>     inet6 ::1/128 scope host 
>>        valid_lft forever preferred_lft forever
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>     link/ether 00:15:17:15:ac:78 brd ff:ff:ff:ff:ff:ff
>>     inet 172.16.32.12/24 brd 172.16.32.255 scope global eth0
>>     inet6 fe80::215:17ff:fe15:ac78/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:1b:21:43:28:58 brd ff:ff:ff:ff:ff:ff
>> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>     link/ether 00:15:17:15:ac:79 brd ff:ff:ff:ff:ff:ff
>>     inet 192.168.0.3/24 brd 192.168.0.255 scope global eth2
>>     inet6 fe80::215:17ff:fe15:ac79/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:1b:21:43:28:59 brd ff:ff:ff:ff:ff:ff
>> 6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:18:8b:4c:7e:7a brd ff:ff:ff:ff:ff:ff
>> 7: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:15:17:15:ac:7a brd ff:ff:ff:ff:ff:ff
>> 8: eth6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:1b:21:43:28:5c brd ff:ff:ff:ff:ff:ff
>> 9: eth7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:15:17:15:ac:7b brd ff:ff:ff:ff:ff:ff
>> 10: eth8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:1b:21:43:28:5d brd ff:ff:ff:ff:ff:ff
>> 11: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>     link/ether 00:18:8b:4c:7e:7c brd ff:ff:ff:ff:ff:ff
>> 12: br-eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
>>     link/ether 00:15:17:15:ac:78 brd ff:ff:ff:ff:ff:ff
>> 13: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
>>     link/ether 1e:ca:81:25:19:4e brd ff:ff:ff:ff:ff:ff
>> 14: phy-br-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>     link/ether 82:d5:6e:2a:bd:87 brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::80d5:6eff:fe2a:bd87/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 15: int-br-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>     link/ether 02:c8:17:03:82:55 brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::c8:17ff:fe03:8255/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 17: qbr44aa454d-9e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
>>     link/ether 82:e3:04:1b:7c:dd brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::9c52:45ff:fee0:5c30/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 18: qvo44aa454d-9e: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>     link/ether 42:5b:38:01:5c:dc brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::405b:38ff:fe01:5cdc/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 19: qvb44aa454d-9e: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr44aa454d-9e state UP qlen 1000
>>     link/ether 82:e3:04:1b:7c:dd brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::80e3:4ff:fe1b:7cdd/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 20: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr44aa454d-9e state UNKNOWN qlen 500
>>     link/ether fe:16:3e:ab:ee:af brd ff:ff:ff:ff:ff:ff
>>     inet6 fe80::fc16:3eff:feab:eeaf/64 scope link 
>>        valid_lft forever preferred_lft forever
>> 
>> ip route:
>> root at FPCompute:~# ip route
>> default via 172.16.32.1 dev eth0  metric 100 
>> 172.16.32.0/24 dev eth0  proto kernel  scope link  src 172.16.32.12 
>> 192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.3 
>> 
>> brctl show:
>> root at FPCompute:~# brctl show
>> bridge name bridge id
>> STP enabled interfaces
>> br-eth0 0000.00151715ac78
>> no eth0
>> phy-br-eth0
>> br-int 0000.1eca8125194e
>> no int-br-eth0
>> qbr44aa454d-9e 8000.82e3041b7cdd
>> no qvb44aa454d-9e
>> vnet0
>> 
>> 
>> 
>> 
>> 
>> Steven Barnabas
>> Network Engineer 
>> Front Porch, Inc.
>> 209-288-5580
>> 209-652-7733 mobile
>> www.frontporch.com
>> 
>> 
>> 
>> On May 17, 2013, at 8:07 PM, Lorin Hochstein <lorin at nimbisservices.com> wrote:
>> 
>>> Steven:
>>> 
>>> Can you paste the output from the following commands on your system?
>>> 
>>> ip a
>>> ip route
>>> brctl show
>>> 
>>> 
>>> Lorin
>>> 
>>> 
>>> On Thu, May 9, 2013 at 8:26 PM, Steven Barnabas <sbarnabas at frontporch.com> wrote:
>>> Ok so every since i sent the  nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1 --network_size=256 --vlan=1 --label=IN-Interface --project=admin --bridge=br-eth4 --bridge_interface=eth4 My compute box cannot ping its own gateway.  Also, my VM's cannot ping outside or any other node on the network.
>>> 
>>> I got everything else back up and running.
>>> 
>>> 
>>> Steven Barnabas
>>> Network Engineer 
>>> Front Porch, Inc.
>>> 209-288-5580
>>> 209-652-7733 mobile
>>> www.frontporch.com
>>> 
>>> 
>>> 
>>> On May 9, 2013, at 3:49 PM, Steven Barnabas <sbarnabas at frontporch.com>
>>>  wrote:
>>> 
>>>> OK, I managed to delete the network through the console by scrubing the project first.  
>>>> 
>>>> Now I have no networks listed in my nova-manage network list but my old network is still showing up in Horizon.
>>>> 
>>>> Should I just delete and start over?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Steven Barnabas
>>>> Network Engineer 
>>>> Front Porch, Inc.
>>>> 209-288-5580
>>>> 209-652-7733 mobile
>>>> www.frontporch.com
>>>> 
>>>> 
>>>> 
>>>> On May 9, 2013, at 3:39 PM, Steven Barnabas <sbarnabas at frontporch.com> wrote:
>>>> 
>>>>> Ok, I did not boot from the console, I booted from Horizon.  So i did not use any options.  
>>>>>  
>>>>> I also assigned the 1.1.1.1/24 to that network in horizon.  It was already part of the project.  
>>>>> 
>>>>> When I did a nova-manage network list on the controller box, it was only showing the 1.1.1.1 network.
>>>>> 
>>>>> I deleted the 1.1.1.1 network to start over through horizon.
>>>>> 
>>>>> So now in Horizon, I see my original network, but when I do a nova-manage network list I still only see the 1.1.1.1  I tried to delete it but it says it cannot be found.
>>>>> 
>>>>> i think i messed something up by using Horizon.  I rebooted the Controller and the Compute box and it still just shows the 1.1.1.1 network.
>>>>> 
>>>>> 
>>>>> Steven Barnabas
>>>>> Network Engineer 
>>>>> Front Porch, Inc.
>>>>> 209-288-5580
>>>>> 209-652-7733 mobile
>>>>> www.frontporch.com
>>>>> 
>>>>> 
>>>>> 
>>>>> On May 9, 2013, at 2:44 PM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>>>>> 
>>>>>> Hi Steven,
>>>>>> 
>>>>>> Great! Now, you might have to assign the network to the project which you will be launching instances from. It'll be something like:
>>>>>> 
>>>>>> nova-manage network modify --fixed_range=1.1.1.0/24 --project=<uuid of project>
>>>>>> 
>>>>>> check "nova-manage network modify" for more info.
>>>>>> 
>>>>>> Then if you do "nova-manage network list" you should see the project uuid listed for two different networks.
>>>>>> 
>>>>>> Thanks,
>>>>>> Joe
>>>>>> 
>>>>>> 
>>>>>> On Thu, May 9, 2013 at 3:16 PM, Steven Barnabas <sbarnabas at frontporch.com> wrote:
>>>>>> ok I did this:
>>>>>> nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1 --network_size=256 --vlan=1 --label=IN-Interface --project=admin --bridge=br-eth4 --bridge_interface=eth4
>>>>>> 
>>>>>> And it worked! 
>>>>>> 
>>>>>> this was the output:
>>>>>> 2013-05-09 14:09:14 DEBUG nova.utils [req-55460cdf-fe87-4f86-9ffb-237dd8024ea9 None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc'> __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:506
>>>>>> 
>>>>>> But….It did not add a secondary Interface when I launched my VNC console to the instance through the gui.  It actually replaced the first network with the second network.  Not adding the second interface.
>>>>>> 
>>>>>> Should I try launching it a different way?
>>>>>> 
>>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> 
>>>>>> Steven Barnabas
>>>>>> Network Engineer 
>>>>>> Front Porch, Inc.
>>>>>> 209-288-5580
>>>>>> 209-652-7733 mobile
>>>>>> www.frontporch.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On May 7, 2013, at 7:18 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>>>>>> 
>>>>>>> Hi Steven,
>>>>>>> 
>>>>>>> Have you tried the --bridge_interface option?
>>>>>>> 
>>>>>>> "nova-manage network create -h" shows both --bridge and --bridge_interface as options. 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, May 6, 2013 at 5:36 PM, Steven Barnabas <sbarnabas at frontporch.com> wrote:
>>>>>>> Ok I changed my /etc/network/interfaces eth-4 interface to manual
>>>>>>> 
>>>>>>> when I do a brctl show this is the output:
>>>>>>> root at FPCompute:~# brctl show
>>>>>>> bridge name bridge id
>>>>>>> STP enabled interfaces
>>>>>>> br-eth0 0000.00151715ac78
>>>>>>> no eth0
>>>>>>> phy-br-eth0
>>>>>>> br-eth4 0000.00188b4c7e7a
>>>>>>> no eth4
>>>>>>> br-int 0000.d6e482502444
>>>>>>> no int-br-eth0
>>>>>>> qbr4ba9f712-ec 8000.7abe7483f8e4
>>>>>>> no qvb4ba9f712-ec
>>>>>>> 
>>>>>>> So the bridge is already there and the interface is mapped to it from what it looks like.  
>>>>>>> 
>>>>>>> When I do this:
>>>>>>> nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1 --network_size=256 --vlan=1 --label=IN-Interface --project=admin --bridge=br-eth4
>>>>>>> I still get the:
>>>>>>> Command failed, please check log for more info
>>>>>>> 2013-05-06 16:18:07 CRITICAL nova [req-9d8bbe89-282c-4490-a3b1-643faeccc849 None None] bridge_interface is required to create a network.
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova Traceback (most recent call last):
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova   File "/usr/bin/nova-manage", line 1404, in <module>
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova     main()
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova   File "/usr/bin/nova-manage", line 1391, in main
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova     fn(*fn_args, **fn_kwargs)
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova   File "/usr/bin/nova-manage", line 480, in create
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova     net_manager.create_networks(context.get_admin_context(), **kwargs)
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova   File "/usr/lib/python2.7/dist-packages/nova/network/manager.py", line 2105, in create_networks
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova     self, context, vpn=True, **kwargs)
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova   File "/usr/lib/python2.7/dist-packages/nova/network/manager.py", line 1461, in create_networks
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova     raise exception.NetworkNotCreated(req=fld)
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova NetworkNotCreated: bridge_interface is required to create a network.
>>>>>>> 2013-05-06 16:18:07 22953 TRACE nova 
>>>>>>> 
>>>>>>> I even tried adding br-eth4 to my /etc/network/interfaces and it still did not work.  I removed that now.
>>>>>>> 
>>>>>>> 
>>>>>>> Steven Barnabas
>>>>>>> Network Engineer 
>>>>>>> Front Porch, Inc.
>>>>>>> 209-288-5580
>>>>>>> 209-652-7733 mobile
>>>>>>> www.frontporch.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On May 4, 2013, at 7:42 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>>>>>>> 
>>>>>>>>> nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1 --network_size=256 --vlan=1 --label=IN-Interface --project=admin --bridge=br-2
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Joe Topjian
>>>>>>> Systems Administrator
>>>>>>> Cybera Inc.
>>>>>>> 
>>>>>>> www.cybera.ca
>>>>>>> 
>>>>>>> Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Joe Topjian
>>>>>> Systems Administrator
>>>>>> Cybera Inc.
>>>>>> 
>>>>>> www.cybera.ca
>>>>>> 
>>>>>> Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>> 
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Lorin Hochstein
>>> Lead Architect - Cloud Services
>>> Nimbis Services, Inc.
>>> www.nimbisservices.com
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130520/437c1a94/attachment-0001.html>

Open Stack

[Openstack-operators] Adding a Physical Network Interface to an Instance

OpenStack

Community

Documentation

Branding & Legal