The router_gateway port appears as DOWN altough it works as expected

[Rami Vaknin]

Version
=======
Havana on rhel

Description
===========
I configured neutron+ovs to work with br-ex, I created the external network as provider-local and connected it manually to a vlan interface (eth3.185), all works, instances can access the outside world and they also accessible from the outside by their floating IPs however neutron reports that the router_gateway is in status DOWN.

Note that I also rebooted the l3 machine to see whether the port is reported as up after reboot - but it stays down after reboot.

# neutron port-show 12f14534-161a-461e-bc12-124552332493
+-----------------------+------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:capabilities | {"port_filter": true} |
| binding:host_id | shtutgmura.redhat.com |
| binding:vif_type | ovs |
| device_id | e8b2c574-0b11-4c96-bed4-731ae6cf0a90 |
| device_owner | network:router_gateway |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "60cad0e1-010a-48a7-9b0c-ed761108653f", "ip_address": "10.35.170.1"} |
| id | 12f14534-161a-461e-bc12-124552332493 |
| mac_address | fa:16:3e:15:d8:07 |
| name | |
| network_id | 236b73a9-0e0f-45b8-b31f-81d187e22c53 |
| security_groups | |
| status | DOWN |
| tenant_id | |
+-----------------------+------------------------------------------------------------------------------------+

# ovs-vsctl show
2fa2a196-9624-4dbe-9a95-a0b63c6bffc0
    Bridge br-ex
        Port "eth3.185"
            Interface "eth3.185"
        Port br-ex
            Interface br-ex
                type: internal
        Port "qg-12f14534-16"
            Interface "qg-12f14534-16"
                type: internal
    Bridge br-int
        Port int-br-nodes
            Interface int-br-nodes
        Port "qr-7fe6f414-05"
            tag: 2
            Interface "qr-7fe6f414-05"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port "qr-e19120f2-f4"
            tag: 4
            Interface "qr-e19120f2-f4"
                type: internal
        Port "qr-13ac173d-41"
            tag: 1
            Interface "qr-13ac173d-41"
                type: internal
        Port "qr-e6e0a3af-50"
            tag: 3
            Interface "qr-e6e0a3af-50"
                type: internal
    Bridge br-nodes
        Port phy-br-nodes
            Interface phy-br-nodes
        Port br-nodes
            Interface br-nodes
                type: internal
        Port "eth3"
            Interface "eth3"
    ovs_version: "1.11.0"

# neutron net-show 236b73a9-0e0f-45b8-b31f-81d187e22c53
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | 236b73a9-0e0f-45b8-b31f-81d187e22c53 |
| name | ext_net |
| provider:network_type | local |
| provider:physical_network | |
| provider:segmentation_id | |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | 60cad0e1-010a-48a7-9b0c-ed761108653f |
| tenant_id | 1532b0139c4f49298dee924500761e6d |
+---------------------------+--------------------------------------+

[Robert Kukura (rkukura)]

I'm not sure this should be considered a bug. You are using br-ex, which bypasses the normal port binding mechanisms, such as a plugin and associated L2 agent. These mechanisms are what manage the port status. Why not just use a provider network for your router's external gateway?

-Bob

[Rami Vaknin (rvaknin)]

I'm using the provider network where possible, vpnaas has a bug which currently forces me to use br-ex.

I'm not sure that external provider network is more common than using the br-ex, but anyway if there is no way to detect that the port is active - the port status should not exists or should be unknown, if it appears as down when the port is up - this certainly considered as a bug.

[Adel (adelgacem)]

Hello,
Dis you sove your problème ?
@del.

[Darragh O'Reilly (darragh-oreilly)]

I booted an Ubuntu Havana system with OVS 1.10.2 and found one problem in this area here. I have no idea what the purpose of these lines is:

https://github.com/openstack/neutron/blob/60cb0911712ad11688b4d09e5c01ac39c49f5aea/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L666-L671

but on this system `sudo ovs-vsctl br-get-external-id br-ex` returns nothing, and so br-ex is excluded from the list of ancillary bridges and so the gateway port always shows as DOWN.

A workaround is to set the bridge-id to br-ex and restart the L2 agent:

sudo ovs-vsctl br-set-external-id br-ex bridge-id br-ex
sudo service neutron-plugin-openvswitch-agent restart

[Gui Maluf Balzana (guimalufb)]

Thanks Darragh, now my network:router_gateway isn't DOWN status anymore. :)

[haruka tanizawa (h-tanizawa)]

So should be set to 'Invalid' if bug doesn't happen anymore?

[ofer blaut (oblaut)]

Issue is not seen in IceHouse

[root@test ~(openstack_admin)]# neutron port-show f56f9d70-af66-4cd9-b48a-e9f9a838d68a
+-----------------------+-------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | test.example.com |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| device_id | d78c2611-08a8-4239-ac35-65d22cf0534d |
| device_owner | network:router_gateway |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "a68e1b46-c659-4ac2-8d59-f1cae9ee89b1", "ip_address": "10.35.180.20"} |
| id | f56f9d70-af66-4cd9-b48a-e9f9a838d68a |
| mac_address | fa:16:3e:97:a2:fb |
| name | |
| network_id | 3f2c3b1d-eb04-418c-bbd0-953388ff7774 |
| security_groups | |
| status | ACTIVE |
| tenant_id | |
+-----------------------+-------------------------------------------------------------------------------------+

[haruka tanizawa (h-tanizawa)]

Issue is not seen in also almost Juno(commit 1aaa8b34466b0567c6a5ea0b607f1ac324ee5dfa).

+-----------------------+-----------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-----------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | ubuntu |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| device_id | d88a8e6a-9132-4174-be1d-3d5d905e8d00 |
| device_owner | network:router_gateway |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "d650879b-6261-423f-b8c5-c26b8971e0e9", "ip_address": "172.24.4.4"} |
| id | da7a82c2-4def-4153-9977-174cbd91a16f |
| mac_address | fa:16:3e:89:0a:80 |
| name | |
| network_id | 553e6d69-a76c-4e30-a522-6c6319a552b3 |
| security_groups | |
| status | ACTIVE |
| tenant_id | |
+-----------------------+-----------------------------------------------------------------------------------+

[Eugene Nikanorov (enikanorov)]

Per latest commits - it works as expected in Icehouse and Juno.

[Darragh O'Reilly (darragh-oreilly)]

The reason for it is so the ovs l2 agent can skip bridges it should not manage - see comments here:
 https://review.openstack.org/#/c/33801/15/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py

and devstack sets it

$ grep -r "bridge-id" devstack/
devstack/lib/neutron_plugins/ovs_base: sudo ovs-vsctl --no-wait br-set-external-id $bridge bridge-id $bridge
devstack/lib/neutron_plugins/ovs_base: sudo ovs-vsctl br-set-external-id $PUBLIC_BRIDGE bridge-id $PUBLIC_BRIDGE

So this is packaging issue.

[Darragh O'Reilly (darragh-oreilly)]

actually maybe this is a doc issue, as the user has to provide and specify the external bridge for the l3-agent

[navin (navinchandra-salunke)]

hi
I am also facing same issue. I have run the command 'sudo ovs-vsctl br-get-external-id br-ex' the o/p: "bridge-id=br-ex" which is correct but still router_gateway port is DOWN.
I can not ping the IP address assigned to it. ( But I can successfully ping using "ip netns <qdhcp-namespace> ping <ipaddress of the port>" command.)
I also observe that all the ports created for floating ip on public networks are in DOWN state.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]