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.

Do you have any good fixes?

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?

@primoz Can you contact me in Slack?

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

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

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

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

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.

Sorry, I have changed the repair implementation
PR: https://github.com/vyos/vyos-1x/pull/638

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