OpenVswitch: qg-XXX goes to br-int instead of br-ext.

Bug #1798536 reported by end-user
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Invalid
Undecided
Unassigned

Bug Description

Rocky version, and Centos 7.5

########### ml2_conf.ini ####

[ml2_type_vlan]
network_vlan_ranges = SDN:450:460,external:20:50

######### openvswitch_agent.ini #####

[ovs]

bridge_mappings = SDN:br-ens224,external:br-ext

I create br-ens224, and add port ens224(NIC name, like ethX) to br-ens224, and create br-ext, add port ens256( NIC name, like ethX) to br-ext.

when I create network( Physical network name is external) and router, I see qg-XXX is in br-int, instead of br-ext.

I try to delete br-* and restart neutron-*, then add bridge/port like before.
qg-XXX is still in br-int.

is is a bug of rocky?

Revision history for this message
end-user (hunter009) wrote :

Currently ovs-vsctl show ouputs:

####################
 Bridge "br-ens224"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "phy-br-ens224"
            Interface "phy-br-ens224"
                type: patch
                options: {peer="int-br-ens224"}
        Port "ens224"
            Interface "ens224"
        Port "br-ens224"
            Interface "br-ens224"
                type: internal
    Bridge br-ext
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-ext
            Interface phy-br-ext
                type: patch
                options: {peer=int-br-ext}
        Port br-ext
            Interface br-ext
                type: internal
        Port "ens256"
            Interface "ens256"
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "qg-b23f041b-80"
            tag: 3
            Interface "qg-b23f041b-80"
                type: internal
        Port "qr-a3a0c537-26"
            tag: 1
            Interface "qr-a3a0c537-26"
                type: internal
        Port "int-br-ens224"
            Interface "int-br-ens224"
                type: patch
                options: {peer="phy-br-ens224"}
        Port "ha-0fae214d-d3"
            tag: 2
            Interface "ha-0fae214d-d3"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port int-br-ext
            Interface int-br-ext
                type: patch
                options: {peer=phy-br-ext}
        Port "tap52a1eec7-b9"
            tag: 1
            Interface "tap52a1eec7-b9"
                type: internal
    ovs_version: "2.9.0"
################################

summary: - OpenVswitch: qg of br-ext is created in br-ext
+ OpenVswitch: qg-XXX goes to br-int instead of br-ext.
Revision history for this message
end-user (hunter009) wrote :

Traffic of Instance goes through ens224(br-int) instead of ens256(br-ext) according to my test. As I remove ens256, Instance is reachable from the outside.

The root cause is that qg-XXX is not in br-ext.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Ports like qg-XXX or qr-XXX should be placed in br-ex directly only in case when You are using "external_network_bridge" config option in L3 agent.

Please note that this option is deprecated and we are in the middle of process to get rid of it: https://review.openstack.org/#/c/567369/

If this option is empty, all ports are connected to br-int and then can be wired by openvswitch/linuxbridge agents as any other ports.

Changed in neutron:
status: New → Invalid
Revision history for this message
end-user (hunter009) wrote :

I do see external_network_bridge in l3-agent.ini, and see the deprecated note as well.

So is there any other way to put qg-XXX in br-ext? external traffic also goes through Nic which br-int attaches, which isn't great.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.