Page MenuHomeVyOS Platform

When the bridge member is a non-ethernet interface, setting VLAN-aware bridge parameters fails
Closed, ResolvedPublicBUG

Description

Configuration doesn't always work:

bridge br0 {

member {
    interface eth1 {
        native-vlan 17
    }
    interface eth3 {
        native-vlan 3333
    }
    interface eth5 {
        native-vlan 93
    }
    interface vxlan17 {
        native-vlan 17
    }
    interface vxlan93 {
        native-vlan 93
    }
    interface vxlan3333 {
        native-vlan 3333
    }
}

}

sometimes result in:

bridge vlan
port vlan ids
eth1 17 PVID Egress Untagged

eth3 3333 PVID Egress Untagged

eth5 93 PVID Egress Untagged

br0 17

93
3333

vxlan3333 1 PVID Egress Untagged

vxlan93 1 PVID Egress Untagged

vxlan17 1 PVID Egress Untagged

and some times in:

$ bridge vlan show
port vlan ids
eth1 17 PVID Egress Untagged

eth3 3333 PVID Egress Untagged

eth5 93 PVID Egress Untagged

br0 17

93
3333

vxlan3333 3333 PVID Egress Untagged

vxlan93 93 PVID Egress Untagged

vxlan17 17 PVID Egress Untagged

It always seem to work on physical interfaces.

Please advise how I can help with debugging

Details

Difficulty level
Easy (less than an hour)
Version
1.3-rolling-202012050217
Why the issue appeared?
Other
Is it a breaking change?
Perfectly compatible

Event Timeline

I don't know what you mean?

Please execute the following command to view the results

bridge vlan show

From the execution results you give, it seems to be normal, but you said that sometimes it will be abnormal?

The relevant code is in:

https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig/bridge.py#L307-L330

Please add the details of this situation, such as the time of occurrence, etc.

I wonder if this configuration should be possible at all. In my opinion native-vlan and allowed-vlan should be supported only on bond and ethernet interface types

Logically speaking, any interface that can be added as a member interface when setting the bridge interface should be fine. bridge vlan applies to any member interface, but I don’t know why it is sometimes possible and sometimes not. I need More information to determine the problem (since there is a situation that can be set successfully, and no abnormality is reported, then the setting should be successful, WLAN is not working because the WLAN bridge is set by hostapd)

From the description, it seems that occasionally the failure of setting bridge vlan occurs

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

I don't understand what you mean, did you tell me or @primoz? Do you mean, temporarily set it to not provide support for other interfaces?

This is usually a bad idea because it artificially limits the range of VLAN-aware bridges that can be used

If the problem cannot be solved, I may restrict the VXLAN tunnel to use VLAN-aware bridge settings

It works nicely with VXLANs ... no problems there. You can use it like this to get local port into vxlan (without this, vxlans become useless). I have problems with bond interface (everything else works). Debugging now.

For some reason ... nothing in logs:

when I try to migrate from:

bridge br2511 {

address 192.168.100.7/24
ip {
    source-validation strict
}
member {
    interface bond0.2511 {
    }
    interface vxlan2511 {
    }
}

}
bridge br2999 {

member {
    interface bond0.2999 {
    }
    interface vxlan2999 {
    }
}

}
bridge br3002 {

member {
    interface bond0.3002 {
    }
    interface vxlan3002 {
    }
}

}

to:

bridge br0 {

member {
    interface bond0 {
        allowed-vlan 2511
        allowed-vlan 2999
        allowed-vlan 3002
    }
    interface vxlan2511 {
        native-vlan 2511
    }
    interface vxlan2999 {
        native-vlan 2999
    }
    interface vxlan3002 {
        native-vlan 3002
    }
}
vif 2511 {
    address 192.168.100.7/24
    ip {
        source-validation strict
    }
}

}

it fails unless I delete original config, commit and then add new config. Will try to locate it. In a two step version .. it work every time.

You mean, if you submit it in 2 steps and configure it separately, it works fine?

yes

first delete original, commit, then new and final commit.

and it works. Without the commit in between ... it sometimes fails.

As it looks to me (but i'm not sure yet), the configuration system is fixing devices one by one and was trying to add port into new bridge before the old bridges were removed (and so ports were still in them). If this is the case ... not sure that there even exist an easy fix.

@c-po Does the deletion of the bridge occur after the new bridge is created or before?

I want to make sure that when the same submission deletes the old bridge and creates a new bridge, should the configuration system delete it first or create it first? I hope to determine this order.

it's an edit + delete/delete/delete ... no creation (at least in my edge case).

@primoz Delete the old one, create a new bridge after commit, and then commit. Can it work normally?

I may have to change the configuration priority. Due to priority issues, the settings may fail

jack9603301 changed the task status from Open to In progress.Dec 8 2020, 1:02 PM
jack9603301 triaged this task as High priority.

@c-po Please merge this PR, the problem will be fixed directly

PR https://github.com/vyos/vyos-1x/pull/638

jack9603301 renamed this task from VLAN-aware bridges + VXLAN to When the bridge member is a non-ethernet interface, setting VLAN-aware bridge parameters fails.Dec 8 2020, 1:53 PM

Tried this patch with @jack9603301 , it solves the problem for me.

jack9603301 changed Difficulty level from Unknown (require assessment) to Easy (less than an hour).Dec 8 2020, 2:18 PM
jack9603301 changed Why the issue appeared? from Will be filled on close to Other.

Unfortunately this is the wrong way to go. If it is - for whatever reason - not possible to configure the VLAN parameters for this given interface b/c the enslaved interface is yet not present on the system, it should be later configured by the individual interface.

Shifting priorities will have all kinds of side effects so they should be kept as is as long as possible. This simply feels like missing glue logic when non existing interfaces are added to a bridge that might already exist - or not.

jack9603301 changed the task status from In progress to Needs testing.Dec 12 2020, 8:46 PM

@primoz Use the latest rolling version test the day after the merge is submitted