Please feel free to do so. Thank you!

So you merged while I was working on fixing the lint. If you care, I pushed an update with the line lengths corrected. Otherwise, feel free to ignore. Your call.
Thanks for the fast response and your patience with me.

That's fair... I'll try to have something in the next few days.

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

Hi @owen, I added a small note about GRE6 some days ago on the bottom of the GRE chapter. https://docs.vyos.io/en/latest/configuration/interfaces/tunnel.html#generic-routing-encapsulation-gre

There’s still the issue of getting it added to the documentation.

@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

Yeah that was my fault. It is already fixed in https://github.com/vyos/vyos-1x/commit/688d749c40d25cbf8ed7f7176d73f0fdd8ee9d51 from T3185

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 :(

Very well.

@tuxis-ie we are running FRR 7.3 and can not easily upgrade to 7.4 due do changes in the FRR behavior and known bugs which we already faced in a rolling release which was running FRR 7.5.

I see it is in https://github.com/FRRouting/frr/releases/tag/frr-7.4 ..

Hmm. It has been merged here: https://github.com/FRRouting/frr/pull/5855

@tuxis-ie
FRR doesn't allow you to set that value. It's not a bug of VyOS.
In commands description allowed values (0-4294967295)

r12-1.2.6(config)# route-map FOO permit 100
r12-1.2.6(config-route-map)# set local-preference 
  (0-4294967295)  Preference value
r12-1.2.6(config-route-map)# set local-preference 
  (0-4294967295)  Preference value
r12-1.2.6(config-route-map)# set local-preference -10
% Unknown command: set local-preference -10

@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.