Ask Your Question
0

quantum stops working after reboot

asked 2013-09-14 04:30:12 -0500

Sifty gravatar image

I have an allinone installation and once i have configured and setup the system quantum networking works brilliantly - however as soon as I reboot the system the quantum networking stops working.

The simple question is - is there something that is not saving persistently system level to cause this... everything looks good just cannot connect to the outside network.

br-ex attach to eth0 192.168.13.101

ovs-vsctl show
705a28da-f95e-41f6-8d2c-d8054f4a6ecd
    Bridge br-ex
        Port "eth0"
            Interface "eth0"
        Port br-ex
            Interface br-ex
                type: internal
        Port "qg-63b891c6-75"
            Interface "qg-63b891c6-75"
                type: internal
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "qvo546e6c1c-d2"
            tag: 1
            Interface "qvo546e6c1c-d2"
        Port "tap9c1ecf66-e9"
            tag: 1
            Interface "tap9c1ecf66-e9"
                type: internal
        Port "qr-5bf39bda-76"
            tag: 1
            Interface "qr-5bf39bda-76"
                type: internal
    ovs_version: "1.11.0"




  ip netns exec qrouter-78b8f87b-b25f-4b73-849d-634042c6fab2 route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   192.168.13.224  0.0.0.0         255.255.255.240 U     0      0        0 qg-63b891c6-75
   10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 qr-5bf39bda-76
   0.0.0.0         192.168.13.225  0.0.0.0         UG    0      0        0 qg-63b891c6-75
   [root@localhost init.d(keystone_demo)]# ip netns exec qrouter-78b8f87b-b25f-4b73-849d-634042c6fab2 ping     192.168.13.227
   PING 192.168.13.227 (192.168.13.227) 56(84) bytes of data.
   64 bytes from 192.168.13.227: icmp_seq=1 ttl=64 time=17.4 ms
   64 bytes from 192.168.13.227: icmp_seq=2 ttl=64 time=0.223 ms

  [root@localhost init.d(keystone_demo)]# ip netns exec qrouter-78b8f87b-b25f-4b73-849d-634042c6fab2 ping 10.0.0.2
 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.453 ms
 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.215 ms

Have a hunch this is something to do with iptables but cannot see what rule is causing the issue at reboot.

iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
quantum-openvswi-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
nova-api-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 3260,8776 /* 001 cinder incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 80 /* 001 horizon incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 9292 /* 001 glance incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 80 /* 001 nagios incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 5000,35357 /* 001 keystone incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 5900:5999 /* 001 nova compute incoming */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 3306 /* 001 mysql incoming */
ACCEPT     tcp  --  0.0.0.0/0 ...
(more)
edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2013-09-14 05:27:26 -0500

Sifty gravatar image

Right after hours of messing around trying to keep the quantum networking persistent... I have worked it out.

Leaving this question though for other users who may have experienced the same problem....

BIG MASSIVE NOTE TO SELF

RTFM

http://docs.openstack.org/folsom/basic-install/content/basic-install_network.html

Reason why not persistent after reboot is because the public floating ip network address is lost on the interface br-ex

So I have a public interface defined in quantum... 192.168.13.224/28 gateway of 192.168.13.225

It must exist on the physical network interface to route out.

ip addr
....
    7: br-ex: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
        link/ether 00:1a:a0:b1:e2:12 brd ff:ff:ff:ff:ff:ff
        inet 192.168.13.101/24 brd 192.168.13.255 scope global br-ex
        inet 192.168.13.225/28 scope global br-ex
        inet6 fe80::cc09:50ff:fe5b:5bb1/64 scope link
           valid_lft forever preferred_lft forever
...

If it does not then bloody create it.

ip addr add 192.168.13.225/28 dev br-ex

That bloody simple... honestly sometimes...

Regards to all openstackers.

edit flag offensive delete link more

Comments

It would be better to set the external quantum subnet with cidr 192.168.13.101/24 and the real gateway for the gateway_ip. Then the main host ip namespace would not need to route everything again and br-ex would not need an ip. Use allocation_pools if only subsets of the cidr are available.

darragh-oreilly gravatar imagedarragh-oreilly ( 2013-09-16 02:45:31 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-09-14 04:30:12 -0500

Seen: 348 times

Last updated: Sep 14 '13