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

When the vyos kernel is higher than 5.8+, you can start the formal test before merging nat66

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

In T915#81521, @Cheeze_It wrote:

@c-po @runar If there are no other problems, I will change the VLAN aware bridge code and update the description of T3137 in the near future

@c-po

There is no need to use set interfaces bridge br1 vlan-aware, as soon as the vif node is present, it will be vlan aware. We should not randomly add all kinds of new CLI nodes.

NTP doesn't work when you configure listen-address 0.0.0.0.

@runar we also added no- in the 1.3 series, so I'd prefer: set interfaces tunnel tun0 parameters ip disable-pmtu-discovery or set interfaces tunnel tun0 parameters ip no-pmtu-discovery

1. vif 1 should not be used as a required option for VLAN-aware bridges, it is only used when Layer 3 routing is required
2. Are native-vlan and allowed-vlan necessary options for VLAN-aware bridges? Worth thinking about? After activating the VLAN-aware bridge function, if you do not set these two options, you can use the default VLAN parameters to run (all untagged packets are members of VLAN 1, which is in line with the behavior of most professional equipment)

There is no need to use set interfaces bridge br1 vlan-aware, as soon as the vif node is present, it will be vlan aware. We should not randomly add all kinds of new CLI nodes.

@runar If we assume that all untagged packets are members of VLAN 1 by default, then the behavior of the device bridge is actually the same as the behavior without VLAN awareness. In this case, set interfaces bridge br1 vlan-aware may not necessary

VLAN-aware bridge is a special use case. We should design additional special rules for VLAN-aware bridges. This rule should be consistent with the behavior of other routers and switch manufacturers, combined with https://phabricator.vyos.net/ According to T1354, can the following changes be considered:

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

I'm sorry for the delay in response but i've now have had time to look at your initial implementation of vlan-aware bridges.
As a first implementation your implementation in T3042 looks it look and feels quite good!
But i've noticed a few things, and have some questions and suggestions:

Seems both sides negotiating at 1450... but Linux interface gets 4 bytes less.

Okay, that old Perl converter really produces crap :(

@c-po Sorry for the late notice on this -- One of the 2020 releases sort-of fixed the issue in my environment. I'm not seeing crashes on the OSPF daemon but I have seen it on occasion with OSPF6 like @maznu mentioned.

VyOS packages are currently beeing regenerated with a fix for this.

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

As far as i know all our other "disable" commands starts wirh "disable-"

I'd personally recommend "pmtu-discovery-disable", but either would be fine.

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

Proposed CLI

set interfaces tunnel tun0 parameters ip disable-pmtu-discovery

@Dmitry Thank you for correcting. I may have got it wrong

@victorhooi try to build a stable version for yourself, on the stable version is defined by udev rules https://github.com/vyos/vyos-build/blob/crux/tools/vendors_udev/64-vyos-SAF51015I-net.rules
Or you can use way with binding hw-id as noticed @jack9603301 (but not mac)

PR https://github.com/vyos/vyatta-cfg-quagga/pull/61

@c-po https://github.com/vyos/vyos-1x/pull/668

@c-po has also tested an iso from the above branches, notably testing a vyatta-wanloadbalance configuration. It had been presumed that the listed dependency of vyatta-wanloadbalance on vyatta-config-migrate was a legacy error, as there were no explicit dependencies, but it required a sanity check. I will merge via PR's, in order to better track the changes over the 3 required packages.

Put PR for segment routing addition:

@maznu I've also been looking at switch to Mellanox cards after my experience with Intel. It's not as if this is a mass consumer product with end-users that don't really know what they're doing. It's a product that's most likely supported by IT/network staff that get to influence purchasing decisions for equipment like this.

@drac, while yes that is an option I am unsure which VyOS should as a software package should use.

Or you could implement import and export policies for BGP, which is what I did.
We already had export policies but it is good practice to have both.

So, this option can be disabled here per the FRR manual:

Just tried this with 7.4 yeah, issue persists. Using 7.3 which is also in the LTS version for so long...

This is due to RFC 8212, which was added on FRR 7.4. Please see here...

Reverting back to 7.4 series until those are resolved.

This infact hit me, too which is super annoying and could kill your entire AS.