Reopened on @Apachez request

ahh.. looking at it now it looks like the new upstream DTB uses lanX for all "lan" switchports..

Enumaration order and names are specified here:
DSA switch ports: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts#L408-L459
CPU Ethernet ports: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts#L171-L198

@Apachez no, they are not mapped by hw-id, all mapping of DSA ports are done by the DTB file (Hardware Device Tree) loaded into the kernel. also the enumeration order of cpu ethX interfaces are specified by the DTB file

I agree with @c-po, no warning is needed inbthis case

Please make it so when both are present the native-vlan command is used.. do not throw an exception as this would make configuration much harder, as a eg. allow-vlan 1-4096, native-vlan 50 will be impossible to configure... Splitting up the allow-vlan and redoing it just to change native-vlan is work that the scripts should do in the backend and not have the user do it

Kernel pipeline merged

What about this? https://docs.vyos.io/en/latest/configuration/firewall/index.html?highlight=Mss#tcp-mss-clamping

The fix submitted is not working as intended.. both - and _ are allowed characters in dns, so this this break dns names with _ in them. Before anyone complains, rfc952 that sets the name definition disallows use of underscore in hostnames and top level domains, not subdomains where the use is fully valid

Ahh.. yea, i see that now.. i've never done this, so cant say how it work.. but as i can se this is still the same process, so my answer is still the same.... Actually this migth be a good reason for migrating set protocols bgp <asn> to its own local-as <asn> subnode, so the AS is not hardcoded in the configpath

@Viacheslav in you example, what does set protocols bgp <asn> vrf do? if i'm reading it correctly it makes no sense as you do not start a new process, and the ASN for the vrf will be the asn of the global bgp process

using set protocols ospf vrf ... makes it harder to show that this is actually multiple processes that co-exist on the router, but on the other hand if we are thinking about the config scripts that are going to execute all this the syntax set protocols ospf vrf.... makes more sense, because the normal ospf config_mode script can program both "global" and all the vrf's

There are differences on vrf support in ospf,++ and BGP. the largest difference is that in IGP's you start a new process for each and every vrf you use. then the syntax set protocols vrf ospf.... makes kinda sense, but on BGP you are only using ONE process and the vrf is only a address-family inside the current process. and there the syntax set protocols bgp X vrf X makes most sense.

In the new xml/py rewrite, do they disapear if you rerun the bgp configurator script? Eg. Can we execute frr-reload twice as a workaround?

Some days ago a cleanup was done on 1.4 to clean away some old legacy code, it looks like this cleanup has removed a bit to much...
https://github.com/vyos/vyatta-cfg-system/pull/136

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

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:

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

vyatta-biosdevname:
https://github.com/vyos/vyatta-cfg-system/blob/ebbdfe44aa321a2de35ddccaa255d384a5fd99e4/scripts/vyatta_net_name#L96
Used for calculating initial interface order, to try getting a ordered list and not only the random init-order used by the kernel

In your example the use of ge is redundant as as you have allready specified a limiting subnettmask you cant go outside the boundry of the prefix specified.

To clarify the fault here. the smoketest is looking for the word "Config()" inside all conf_mode scripts without taking into account that this could be part of another name. the patch above modifies the behavior to not mat when a alpha-character is in front of the C in Config.
full regex: [^a-ZA-Z]Config\(\)

Does this mean to to disallow installing the syslinux bootloader to the iso by default? The reason for asking is the arm builds we try to make, as syslinux is incompatible with arm, and a iso cant be generated for such a system as it tries to install syslinux when building the image.

@Dmitry I dont really know if this is a good idea.
The reason for this is that the configuration synchronisation between frr daemons depends on the daemons started at the same time, and always running when global configuration is applied.. this is also one of the reasons why frr-daemons starts prior to vyos starting on bootup and not when a daemon is configured. I do not know if this will be a issue with PIM, so i'm not sure what will happen with this daemon.
as an example for such synctonization is a prefix-list.
If you start bgp and ospf and then create a prefix-list, the list will be created in both ospf and bgp.
If you start bgp , then create the prefix-list and then start ospf, ospf will not automatically add the prefix-list but when you show the combined configuration is is still show'ed as a global prefix-list.. to get the prefix-list into ospf you need to manually add the commands to the daemon to get in sync.

In the example above you only included the header, could you extend the examples with example information you want to display there?

it sounds good to me.
I personally think the days with manually locking nic queues to cpu's is a bit outdated and we need something more dynamic.
After reading a bit on tuned i give my thumbs up

@c-po i agree with using "native-vlan", but i dont agree on using "allowed-vlan".
"allowed-vlan" for me it dosn't actually describe that this vlan will be tagged on the port

Hmm.. i have a few sugestions about the syntax.
The linux kernel allows the user to have different pvid vlan's on ingress and egress of a router port,.

• this is if you ask me not a common use case and i think we should merge the pvid(ingress) and untagged(egress) so that they will be ONE command..
• my second note is that the syntax shown above is quite verbose when creating a lot of vlan's and interfaces. consider creating 20 vlans on 5 ports, that will make a minimum of 100 lines of code in the config.

i would like to purpose a different syntax like this:

# Enable vlan filtering
set interfaces bridge br1 vlan

In T766#77850, @jack9603301 wrote:

What information do you need access to from within op-mode?

Since restarting tinc requires resetting the interface, it means that you may need to get all the configuration information to call the update function settings of the interface class

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

It seems that we need to think about it now

You can pull the host configuration in operation mode using the following command:

generate tinc tincN host-conf <user@service:/path>

Note: my test found that when the server is in switch mode, the client cannot Ping to the peer in routing mode (more tests may be needed)

the issue is verified by soxrok2122 by using a stock ubuntu 20 host with the stock vyos/vyos-build:current-arm64 docker image

I'm reopening this issue as this seams to still be an issue. reported by user soxrok2212 on slack (#vyos-on-arm64)

I think we could generate private/public keys using openssl instead of using the tinc utility to generate it... But i have not tested it

placing the tinc deb in vyos-build/packages is appropriate while writing support for tinc, but for building on a production iso that is distribute it is not appropriate.. but it's quite easy to add the package to our own repository if we need that...

The version of tinc vpn supplied with buster is 1.0.35, and 1.1-pre17 is only availabe in the experimental repository as for now. The first release of 1.1pre is from 2011 and i would say that it is quite mature at this point.

This is disallowed by design by the VyOS team. the reason for this is partly because of the configuration order done by VyOS and how the dns lookup is handled by Wireguard.
Yes, the wg configuration utillity DOES handle DNS lookups, but NO, Wireguard does not handle them. This means that the DNS lookups is done once (and only once) when the wg command is executed on creation of the tunnel and then the resulting ip result is stored in wireguard. this results in the dns lookup will fail after a reboot of the VyOS device because it cant resolve the dns of the endpoint at that point (this is done before routing is enabled on the device)

In T2508#74559, @dongjunbo wrote:

why don't we chang unbound to coredns ? Coredns will be more stronger thant unbound.