Ask Your Question

Cause for strange network config?

asked 2015-06-02 22:08:46 -0500

Bernd Bausch gravatar image

Trying to set up Kilo on Centos according to the install guide, I hit a brick wall with neutron configuration.

This is what I expect on the network node after launching an instance and associating a floating IP with it:

  • The qrouter-xxxxx NW namespace has NAT configured, and contains the router's gateway interface with the floating IP
  • br-ex contains the router's gateway interface, qg-yyyyyyy

Instead, I don't see any NAT, and qg-yyyyyy is plugged into br-int. Details below.

Any idea what misconfiguration could cause this? I have gone over the config files several times and can't find anything wrong. If you have suggestions what to look for in the database, they would be welcome as well.

Or is the config correct, and the fact that I can't ping my instance is caused by something else? (but how is a packet supposed to go to the instance without NAT??)

Below: No NAT. The router's IP is, the floating IP is - at least that has been configured.

# ip netns exec qrouter-3baec6ff-2dcd-4eae-b6e7-4e10e6610df9 sh
# ip a
(removed interfaces lo and qr-zzzzzzz)
12: qg-9f212d17-bb: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:76:75:9e brd ff:ff:ff:ff:ff:ff
    inet brd scope global qg-9f212d17-bb
       valid_lft forever preferred_lft forever
    inet brd scope global qg-9f212d17-bb
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe76:759e/64 scope link 
       valid_lft forever preferred_lft forever

# iptables -S
-N neutron-filter-top
-N neutron-l3-agent-FORWARD
-N neutron-l3-agent-INPUT
-N neutron-l3-agent-OUTPUT
-N neutron-l3-agent-local
-A INPUT -j neutron-l3-agent-INPUT
-A FORWARD -j neutron-filter-top
-A FORWARD -j neutron-l3-agent-FORWARD
-A OUTPUT -j neutron-filter-top
-A OUTPUT -j neutron-l3-agent-OUTPUT
-A neutron-filter-top -j neutron-l3-agent-local
-A neutron-l3-agent-INPUT -m mark --mark 0x1 -j ACCEPT
-A neutron-l3-agent-INPUT -p tcp -m tcp --dport 9697 -j DROP

Below: Strange OVS config. Note that br-int contains the qg-yyyy interface, which I would expect to be plugged into br-ex.

# ovs-vsctl show
    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "eth3"
            Interface "eth3"
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-0a000183"
            Interface "gre-0a000183"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-int
        fail_mode: secure
        Port "qg-9f212d17-bb"
            tag: 2
            Interface "qg-9f212d17-bb"
                type: internal
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "qr-3ae9346b-a8"
            tag: 1
            Interface "qr-3ae9346b-a8"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port "tap3c4dc956-08"
            tag: 1
            Interface "tap3c4dc956-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    ovs_version: "2.3.1"
edit retag flag offensive close merge delete


Embarrassing mistake. NAT exists if I use iptables -t nat.

Bernd Bausch gravatar imageBernd Bausch ( 2015-06-03 00:15:38 -0500 )edit

4 answers

Sort by ยป oldest newest most voted

answered 2015-10-04 22:00:45 -0500

penghon gravatar image

From my own testing only the qg-yyyy interface will only be associated with the external network openvswitch br-external (or whatever you call it) when you have the following configured: external_network_bridge = br-ex

This lead me to have issues creating multiple external gateways.

I have also used packstack to create the config in both kilo and Juno. Same result.

edit flag offensive delete link more

answered 2015-08-17 01:17:09 -0500

A.g gravatar image

hi, i installed openstack kilo . when i write ifconfig command i dont have br-ex & br-int interface in my list . please help me . how can i configure these interfaces??

edit flag offensive delete link more

answered 2015-07-06 11:54:06 -0500

rvarghese gravatar image

updated 2015-07-06 12:00:05 -0500

I had faced same issue but resolved by setting the external_network_bridge to br-ex. As per the documentation "The external_network_bridge option intentionally lacks a value to enable multiple external networks on a single agent."

After changing this I dropped the database and recreated it.

My configuration.

[root@network ~]# grep -v ^# /etc/neutron/l3_agent.ini | grep -v ^$
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge = br-ex
router_delete_namespaces = True
verbose = True
edit flag offensive delete link more

answered 2015-06-03 00:53:13 -0500

dbaxps gravatar image

updated 2015-06-03 05:36:39 -0500

I went through

In section "Install and configure controller node"  they configure ml2_conf.ini and populate neutron database
In section "Install and configure network node"  they configure ml2_conf.ini on network node what looks like
post neutron database generation procedure and might potentially cause problems

At least packstack ( view ) doesn't do that. Packstack does on Controller

   [root@ip-192-169-142-127 neutron(keystone_admin)]# cat plugin.ini | grep -v ^$|grep -v ^#
   type_drivers = vxlan
   tenant_network_types = vxlan
   mechanism_drivers =openvswitch
   vni_ranges =1001:2000
   vxlan_group =
   enable_security_group = True

Packstack creates on Network node only ovs_neutron_plugin.ini like on Compute.

[root@ip-192-169-142-147 openvswitch(keystone_admin)]# cat ovs_neutron_plugin.ini | grep -v ^$| grep -v ^#
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip =
bridge_mappings =physnet1:br-ex
polling_interval = 2
tunnel_types =vxlan
vxlan_udp_port =4789
l2_population = False
arp_responder = False
enable_distributed_routing = False
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

If ml2-conf.ini generated via my answer-file doesn't satisfy you , update answer-file as you need and run deployment via packstack. At least via my experience RDO Kilo Multi Node packstack deployment, it generates normal OVS configs on Network && Compute Nodes , and finally creates stable working system.

Of course I realize that it's not addressing your question, however , provides an option which works not only  for myself. You may also run packstack in dialog and it will generate answer-file for you automatically, then prompt you to start deployment and finally successfully complete deployment.

View :

edit flag offensive delete link more


Thanks Boris. Packstack is not an option, as my goal is to try the install guide. I will still try your ini files (the install guide uses GRE, not VXLAN though), but in the end I think I did something wrong that corrupted the database.

Bernd Bausch gravatar imageBernd Bausch ( 2015-06-04 02:55:29 -0500 )edit

Type of tunneling really doesn't matter.

dbaxps gravatar imagedbaxps ( 2015-06-04 03:12:28 -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


Asked: 2015-06-02 22:08:46 -0500

Seen: 415 times

Last updated: Oct 04 '15