Ask Your Question
1

Port on router to public gateway always down.

asked 2013-12-07 23:59:04 -0500

robparrott gravatar image

updated 2013-12-08 00:01:17 -0500

I've seen this question asked a couple times but none of the responses appear to fit.

I'm seeing the behavior that no matter what I do, the port on a basic router to the public network remains down. This setup is Neutron/Havana with OpenVSwitch+GRE on CentOS/RHEL 6.5. I've been able to see L2 and L3 routing working from VMs, just not outward connectivity due to this issue (the gateway port remains down).

The router in question is as follows:

+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                          |
+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
| 3ff39a23-4205-4c43-ab7e-9503354a30f3 |      | fa:16:3e:cd:9d:8e | {"subnet_id": "0381e5dd-a3ec-4ab1-aa9e-801706f02966", "ip_address": "10.255.73.2"} |
| 81269f0d-a704-4cc9-871e-ff3cd1774f96 |      | fa:16:3e:3a:e8:5c | {"subnet_id": "3297725c-5def-45f1-a4cb-b3931bd0d9ea", "ip_address": "10.0.1.1"}    |
| 87ddff08-a365-4285-b8ea-d176a180f7e8 |      | fa:16:3e:7d:d1:46 | {"subnet_id": "9e16cce1-dc78-4206-a195-d589f319e4b4", "ip_address": "10.0.0.1"}    |
+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+

with the problematic network (10.255.73.0/24) attached as a gateway on port:

+-----------------------+------------------------------------------------------------------------------------+
| Field                 | Value                                                                              |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                               |
| allowed_address_pairs |                                                                                    |
| binding:capabilities  | {"port_filter": true}                                                              |
| binding:host_id       | ospoc4.lab.xxx                                                        |
| binding:vif_type      | ovs                                                                                |
| device_id             | 38eea523-ca75-4410-9a28-d0686a2173fe                                               |
| device_owner          | network:router_gateway                                                             |
| extra_dhcp_opts       |                                                                                    |
| fixed_ips             | {"subnet_id": "0381e5dd-a3ec-4ab1-aa9e-801706f02966", "ip_address": "10.255.73.2"} |
| id                    | 3ff39a23-4205-4c43-ab7e-9503354a30f3                                               |
| mac_address           | fa:16:3e:cd:9d:8e                                                                  |
| name                  |                                                                                    |
| network_id            | 715c189b-c79d-4abf-876d-a8cba83b41de                                               |
| security_groups       |                                                                                    |
| status                | DOWN                                                                               |
| tenant_id             |                                                                                    |
+-----------------------+------------------------------------------------------------------------------------+

The problem seems to be with the "ip" command calls to the created interface, in this case named "qg-3ff39a23-42".

The logs (secure and openvswitch) show that the new interface was successfully added to the "br-ex" bridge, but certain commands fail to find the device. The commands called (wrapped by neutron-rootwrap) are as follows:

ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 

ovs-vsctl -- --may-exist add-port br-ex qg-3ff39a23-42 -- set Interface qg-3ff39a23-42 type=internal \
      -- set Interface qg-3ff39a23-42 external-ids:iface-id=3ff39a23-4205-4c43-ab7e-9503354a30f3 \
      -- set Interface qg-3ff39a23-42 external-ids:iface-status=active \
      -- set Interface qg-3ff39a23-42 external-ids:attached-mac=fa:16:3e:cd:9d:8e

ip link set qg-3ff39a23-42 address fa:16:3e:cd:9d:8e 
ip link set qg-3ff39a23-42 netns qrouter-38eea523-ca75-4410-9a28-d0686a2173fe

ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip link set qg-3ff39a23-42 up 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip addr show qg-3ff39a23-42 \
      permanent scope global 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -4 addr add 10.255.73.2/24 brd \
      10.255.73.255 scope global dev qg-3ff39a23-42 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe arping -A -U \
      -I qg-3ff39a23-42 -c 3 10.255.73.2

Most of the commands succeed, except for the two ip link set ... commands which return

Cannot find device "qg-3ff39a23-42"

At first glance, this looks like a resolution failure since the commands aren't namespaced properly. This OS supports namespaces:

# ip -o netns list
qrouter-38eea523-ca75-4410-9a28-d0686a2173fe

The other ip commands seem to find the device properly. For example, the ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 command returns:

21: qg-3ff39a23-42: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN \    link/ether fa:16:3e:cd:9d:8e brd ff:ff:ff:ff:ff:ff

Though it doesn't report being in state UP, instead is in state UNKNOWN.

The gateway port seems to be on the right bridge, since ovs-vsctl show reports

Bridge br-ex
    Port br-ex
        Interface br-ex ...
(more)
edit retag flag offensive close merge delete

Comments

@robparrott did you solved this? I'm at the same point.

juliansotoca gravatar imagejuliansotoca ( 2014-07-25 09:54:19 -0500 )edit

I have the same problem. If you solved, please comment us.

DaOmarN gravatar imageDaOmarN ( 2014-08-03 01:45:28 -0500 )edit

3 answers

Sort by ยป oldest newest most voted
0

answered 2014-02-02 12:55:11 -0500

Gamekiller77 gravatar image

First Off i have the same problem with my router port on my public network showing down. I found this problem while i was searching for why the port was down.

One thing i found was the order in which i built the network setup. I had to first build the pulbic network and floating ip pool. then the subnet stuff. then the private network then subnet. Then create a router and add the private network. Last add the public network GW and boom it worked. So odd i heard this was a problem non to the neutron setup with CentOS and RDO build.

If i find my fix i post it here too.

Andy

edit flag offensive delete link more

Comments

Andy, any fix found?

Robert Campbell gravatar imageRobert Campbell ( 2014-04-07 10:03:52 -0500 )edit
0

answered 2015-12-04 07:11:15 -0500

Hi, I have the same problem for my new openstack installation on full ubuntu environnement.

I'm facing a strange behavior. I cannot get the ip address configured on my new created instances and I cannot reach external network using floating ip. The external port is DOWN all the time.

root@network:~# ovs-vsctl show

e7f681db-e5ff-4325-81ce-c6b04b36f3c0 Bridge br-int fail_mode: secure Port "tap5f030d6d-19" tag: 1 Interface "tap5f030d6d-19" type: internal Port br-int Interface br-int type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "qr-ecb50bf4-95" tag: 1 Interface "qr-ecb50bf4-95" type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port "qg-6b6290df-da" Interface "qg-6b6290df-da" type: internal Port "enp0s9" Interface "enp0s9" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Bridge br-tun fail_mode: secure Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "gre-0a00011f" Interface "gre-0a00011f" type: gre options: {df_default="true", in_key=flow, local_ip="10.0.1.21", out_key=flow, remote_ip="10.0.1.31"} Port br-tun Interface br-tun type: internal ovs_version: "2.4.0" root@network:~#

root@network:~# ip netns exec qrouter-981e85cc-0af9-42d2-980c-373f95e057f0 ip -o link show qg-6b6290df-da

15: qg-6b6290df-da: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default \ link/ether fa:16:3e:45:f9:af brd ff:ff:ff:ff:ff:ff root@network:~# ip netns exec qrouter-981e85cc-0af9-42d2-980c-373f95e057f0 ip link 1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 14: qr-ecb50bf4-95: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether fa:16:3e:2f:a4:a5 brd ff:ff:ff:ff:ff:ff 15: qg-6b6290df-da: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether fa:16:3e:45:f9:af brd ff:ff:ff:ff:ff:ff

I'm using Virtual box, I configured promiscuous mode on external physical interface which is not configured with an IP address.

Is there any neutron/OVS bug ?

edit flag offensive delete link more
0

answered 2014-02-03 01:41:29 -0500

Sadique Puthen gravatar image

updated 2014-02-20 05:45:42 -0500

I heard this would work if you use a provider external network ie external_network_bridge =

I heard if not using provider external network. ie external_network_bridge = br-ex, then the external interface would always be shown as down since there is nothing available to monitor the interface in this use case.

In both cases, I have heard connection to external network from instances would work, but the status would be shown as "Down" in the latter scenario which is a limitation as there is no way to get the status of interface in this scenario.

edit flag offensive delete link more

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

6 followers

Stats

Asked: 2013-12-07 23:59:04 -0500

Seen: 12,072 times

Last updated: Dec 04 '15