Bug 1054857 - router external gateway interface is always down
Summary: router external gateway interface is always down
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.0 (RHEL 7)
Assignee: Maru Newby
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-17 15:37 UTC by Eric Rich
Modified: 2019-01-16 15:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-16 10:15:12 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 728613 None None None Never
Launchpad 1253634 None None None Never

Description Eric Rich 2014-01-17 15:37:51 UTC
Description of problem:

The router for a tennant seems to always have the external gatway interfaces marked as down. 

Example: 

#neutron router-port-list --column id --column status --column fixed_ips router
+--------------------------------------+--------+------------------------------------------------------------------------------------+
| id                                   | status | fixed_ips                                                                          |
+--------------------------------------+--------+------------------------------------------------------------------------------------+
| 726b5e93-0aa7-482d-9bbb-4dcfbfb33191 | ACTIVE | {"subnet_id": "b54f333e-a8b6-4e0d-8c59-93519a9fa728", "ip_address": "8.8.8.1"}     |
| a5bb0a61-cf2d-4762-a132-9e458bde1677 | ACTIVE | {"subnet_id": "42f7dd99-dda8-4364-b0c1-c19e637bd10f", "ip_address": "7.7.7.1"}     |
| f367b1a7-41c2-48c2-9ebe-77e75d941330 | DOWN   | {"subnet_id": "2c0b63a5-c8a4-49b3-a208-c5b6bdc69fcd", "ip_address": "10.10.72.30"} |
| f8814e7e-6c88-4cb7-afaf-a48392a4063a | ACTIVE | {"subnet_id": "dca28905-699e-44bf-a7c1-1773203050a3", "ip_address": "6.6.6.1"}     |
+--------------------------------------+--------+------------------------------------------------------------------------------------+

Version-Release number of selected component (if applicable):

    3.0 and 4.0

How reproducible:

  Steps to Reproduce:
  1. Create a project
  2. Add a network
  3. Define a router (and set the external gateway to be an external network). 

Actual results:

see description. 

Expected results:

External gateway should show status as ACTIVE

Comment 2 Ofer Blaut 2014-01-30 12:56:32 UTC
There is an upstream bug on it https://bugs.launchpad.net/neutron/+bug/1253634

Comment 3 Bob Kukura 2014-02-12 18:15:14 UTC
The router's gateway port's status is correctly managed for provider external networks. When using external_network_bridge ('br-ex'), no L2 agent is involved, so there is nothing that can actively manage the port state. I don't consider this a bug. 

I consider the external_network_bridge a hack that is outliving its usefulness. It was originally introduced because provider networks were not yet implemented. Only provider external networks enable easy sharing of the same NIC for tenant and external networks. Only privder external networks can be directly attached by VMs when neutron routing is not needed. Now (in icehouse at least), multiple external networks can be used with the same l3-agent, but only if they are provider external networks. 

I don't see the point in investing effort and increasing complexity in order to make the external_network_bridge hack look a bit more like a real virtual network connection.

Comment 4 Ofer Blaut 2014-02-13 07:00:16 UTC
Hi Bob

qg interface appears in both CLI & OVS output

I think it should behave same as rest of the ports 

Thanks

Ofer 


root@puma04 ~(keystone_admin)]# neutron port-show 7c5ae8e7-0664-4566-8706-ca95e5ab0832
+-----------------------+-------------------------------------------------------------------------------------+
| Field                 | Value                                                                               |
+-----------------------+-------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                |
| allowed_address_pairs |                                                                                     |
| binding:capabilities  | {"port_filter": true}                                                               |
| binding:host_id       | puma05.scl.lab.tlv.redhat.com                                                       |
| binding:vif_type      | ovs                                                                                 |
| device_id             | d4378ba7-6bf8-46b6-a1d7-e7d2f54819bb                                                |
| device_owner          | network:router_gateway                                                              |
| extra_dhcp_opts       |                                                                                     |
| fixed_ips             | {"subnet_id": "69e7cbe2-c258-4ae4-bc69-b49425b94916", "ip_address": "10.35.180.20"} |
| id                    | 7c5ae8e7-0664-4566-8706-ca95e5ab0832                                                |
| mac_address           | fa:16:3e:e8:d9:df                                                                   |
| name                  |                                                                                     |
| network_id            | 1ec80000-d0ae-4b3d-b450-e34c0a592606                                                |
| security_groups       |                                                                                     |
| status                | DOWN                                                                                |
| tenant_id             |                                                                                     |
+-----------------------+-------------------------------------------------------------------------------------+



[root@puma05 ~]# ovs-vsctl show
9386551f-4143-424b-a94a-e68f75dcd024
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
        Port "qg-7c5ae8e7-06"
            Interface "qg-7c5ae8e7-06"
                type: internal



[root@puma05 ~]# ovs-ofctl dump-ports-desc br-ex
OFPST_PORT_DESC reply (xid=0x2):
 2(eth3.195): addr:80:c1:6e:07:d2:4c
     config:     0
     state:      0
     current:    10GB-FD FIBER
     advertised: FIBER
     supported:  FIBER AUTO_PAUSE
     speed: 10000 Mbps now, 0 Mbps max
 4(phy-br-ex): addr:22:39:48:fa:2a:c4
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 6(qg-7c5ae8e7-06): addr:7c:01:00:00:00:00
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-ex): addr:80:c1:6e:07:d2:4c
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

Comment 6 Assaf Muller 2014-03-16 10:15:12 UTC
Further clarification following Bob's comment:
There's two different ways to connect a router to its external network. The old approach, using br-ex. The router's external leg is connected to br-ex, and br-ex is connected to some NIC which is connected to an external network. With this old approach you cannot hook up multiple external networks to a L3 agent (So that each router may be connected to a different external network). The new approach uses provider networks, so that the external leg of a router is connected back to br-int, and flows are installed on br-int connecting it to a bridge, which is connected to a physical NIC. This way, you can create multiple external networks on a L3 agent. This code was backported to RHOS 4.0.

To conclude, the old approach is no longer being worked on, and the new approach doesn't have this bug. We just have to make sure that the deployment tools are setting the correct values so that we work with the new approach by default (External bridge should be empty or 'provider', and the provider network fields have to be filled out for the L3 agent conf).

Comment 7 Sadique Puthen 2014-03-17 08:26:57 UTC
FYI, I have written an article on this. https://access.redhat.com/site/solutions/728613 We can consider this for our doc.

Comment 8 Amer Hwitat 2019-01-16 13:45:17 UTC
I'm working on RHEL 7 with Openstack 14 on VMware VM, the router interfaces on neutron is down on horizon, I treid solutions with vBridge or without vBridge, didn't work also your solution didn't work with me, I tried the following links:

https://www.linuxtechi.com/install-us...

https://access.redhat.com/documentati...

https://ask.openstack.org/en/question...

didn't work, my VM External eno16377736 IP is 192.168.43.77

I used the following to install openstack:

#
systemctl disable NetworkManager

systemctl stop NetworkManager

systemctl disable firewalld

systemctl stop firewalld

setenforce 0

systemctl restart network

systemctl status network

#
subscription-manager list --available

subscription-manager attach --pool=

subscription-manager repos --enable=rhel-7-server-optional-rpms \ --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms

subscription-manager repos --enable=rhel-7-server-openstack-14-rpms

subscription-manager repos --enable=rhel-7-server-openstack-14-devtools-rpms

subscription-manager repos --enable=rhel-7-server-openstack-14-tools-rpms

yum repolist enabled #enable all

subscriptiion-manager repos --enable=

yum install -y yum-plugin-priorities yum-utils

yum install openstack-selinux

rpm -q --whatprovides rubygem-json ###### rubygem-json-1.7.7-20.el7.x86_64

yum install -y openstack-packstack

#
also this didn't work with me:

ovs-vsctl add-br br-ex

ip addr add 192.168.43.77/24 dev br-ex

ip addr flush dev eno16777736

ip addr add 192.168.43.77/24 dev br-ex

ovs-vsctl add-port br-ex eno16777736

ip link set dev br-ex up

virsh net-define /tmp/ovs-network.xml \ Network ovs-network defined from /tmp/ovs-network.xml

and this:

neutron net-create External1 --provider:network_type flat --provider:physical_network br-ex --router:external=true --shared

neutron net-create External2 --provider-physical-network provider --provider:physical_network eno16777736 --router:external=true --shared

openstack subnet create --network provider \ --allocation-pool start=192.168.43.1,end=192.168.43.240 \ --dns-nameserver 192.168.43.1 --gateway 192.168.43.1 \ --subnet-range 192.168.43.0/24 provider

mysql

create database neutron; grant all privileges on neutron.* to 'neutron'@'localhost' identified by 'server'; grant all privileges on neutron.* to 'neutron'@'%' identified by 'server'; quit

export | grep OS_declare -x OS_AUTH_URL="https://192.168.43.77:5000/v3"

source admin-openrc.sh

openstack user create --domain default --password-prompt neutron

openstack role add --project service --user neutron admin

openstack service create --name neutron --description "OpenStack Networking" network

openstack endpoint create --region RegionOne network public http://controller:9696

openstack endpoint create --region RegionOne network internal http://controller:9696

openstack endpoint create --region RegionOne network admin http://controller:9696

systemctl enable neutron-server.service neutron-openvswitch-agent.service neutron-dhcp-agent.service neutron-metadata-agent.service neutron-ovs-cleanup.service

systemctl start neutron-server.service neutron-openvswitch-agent.service neutron-dhcp-agent.service neutron-metadata-agent.service neutron-ovs-cleanup.service

Comment 9 Amer Hwitat 2019-01-16 13:52:19 UTC
it's the same problem on RHEL 7.0, and RED HAT OpenStack 14, I have openvswitch installed and configured and br-ex bridge configured, and running with eno16777736 interface on a VM, and neutron also is configuered I followed the configurtion file .ini , like what they did in the case in:
https://openstack-xenserver.readthedocs.io/en/latest/10-install-networking-neutron-on-controller.html
https://ask.openstack.org/en/question/25234/one-router-port-is-always-down/ https://www.linuxtechi.com/install-use-openvswitch-kvm-centos-7-rhel-7/
https://ask.openstack.org/en/question/109367/how-to-debug-the-routers-interface-all-the-interfaces-status-are-down/

it's not working.. if there is another fix, it might help ...  or is it a serious bug in the system, I'm a Trainer and learning about openstack and linux please help, if there is a place to post this with pictures it would help too...

Thanks

Comment 10 Brian Haley 2019-01-16 15:01:03 UTC
Amer - it doesn't look like you have enabled/started the l3-agent.  Let's continue discussion in the upstream bug, https://bugs.launchpad.net/neutron/+bug/1811941

Also, it's best to not re-open a four year old bug for a new issue, thanks.


Note You need to log in before you can comment on or make changes to this bug.