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.

Yes, nft_chain_nat_ipv6 is also affected by this, and needs the same adjustments as the nat module

Merged

PR: https://github.com/vyos/vyos-build/pull/116

PR Merged

PR: https://github.com/vyos/vyatta-cfg-system/pull/127

Container fixed, closing this ticket

The CI is now extended to build arm containers by default. they are also exported to dockerhub. closing this ticket

This could be closed in its current form, i'll open a new ticket om the missing parts

Please consider using zeromq instead of pynng

I have to say i agree with @c-po, i see no real reason for changing this. But it could be added as an optional executable but not changing our internal tools to use it. -1

Ref: https://lists.zx2c4.com/pipermail/wireguard/2018-December/003704.html

This s expected wireguard behavior.

As i remember the lack of multicast replication was the reason this stopped up last time it was discussed... And as ospf and eigrp is the most used protocols run over dmvpn i think this is a showstopper for implementimg nhrpd

While you are working on this, there is a need for a render function that does return the template as an variable instead of saving it to a file.
could you extend your patch to also include such a function? if written correctly it could be used by the render() function to not duplicate code.

https://github.com/vyos/vyos-1x/blob/current/debian/control

Hi! This PR does the wrong approach for adding this command to the vyos system. As this is a utility that should be used from within the CLI it should be added to the cliwith the xml framework inside vyos-1x, and rhen should be a dependency of vyos-1x, and not to vyos-build

After some benchmarking of this code i have i've gotten hold of a quite large test configuration that takes a waste amount of time to load into vyos.

The same for ipv6 is available under set system ipv6 layer4-hashing

HI! On 1.3 layer4-hashing is activated by using the set system ip layer4-hashing command

About is_changed, i see the need to have a function that tells if there are any changes in the path tree under the given path.. specified.

Good point, get_value_changed is a better name for this. As you want to distinguish between a returned value of False and a "Not Changed" using a two tuple (namedTuple?) returned with new and old value makes it easy to "see" the difference

Also, as everything set in python will render True, couldn't is_value_changed return the old and new value instead of just true/false? This will make get_value_changed redundant

What about providing a is_changed, that returns False, added, deleted or changed with the new value provided in the result? Added/deleted/changed can be of a enum type or something like that

There are allready someone trying to make a guide for building vyos on arm and the pi3/4, i myself have made it work on the pi4 some time ago but did not save my work so i dont have all the steps to reproduce..

Please open a new ticket or move your comment to an appropriate ticket, this ticket is not discussing your consernes.

PR for FRR code in vyos-1x : https://github.com/vyos/vyos-1x/pull/483/files

PR for fixing frr-reload: https://github.com/vyos/vyos-build/pull/111

I agree with @jack9603301 on this, as fastnetmon is not a ids solution, and only focuses on ddos protection it is best to avoid ids in the command syntax alltogether...

As a side-note, the kernel reacts correctly to this by rfc6145.

An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes.

i'm wondering if this is the right approach.
This works as a workaround, but this needs to be added to the ipaddrcheck validator as an allowed host-address and not be done in a shell script

Yes, we need to try/except the apply section (the other should never fail but we could still catch errors to not leave the system in an unknown state) but when applying the reverse configuration (ie: invert effective and new and re-apply) one must then be careful if that fails too (we do not want a forever loop :p). The code already runs all the get_dict and all the verify first, so we will only apply if all is ok, but still issues could occur.

About rollback, i'm wondering about a try:expect loop around apply() that will catch faults and trigger a rollback() to restore old files etc.
The rollback won't be a 100% abort, because vyatta-cfg would not rollback subsystems that have allready been configured.. but we will get a pr. Subsystem rollback and thats a start :) to get a full rollback wee need to change the backend or the executor in the backend.

Here comes some suggestions from my part :)

As the current "priority map" there aren't a loot of concurrent python blocks, but i think many of the remaining bash/perl scripts could be moved to new places. https://pastebin.com/z6ZvkJKB

I've created some proof of concept code that i think could help on this issue. https://github.com/runborg/vyos-1x/blob/main-cfg/src/conf_mode/main.py this is a conf-mode executor that handles multiple conf mode scripts. The reason i think this could seriously help on this issue is that as this is all running inside a single python tnterpreter, its able to load the config object once and pass it to all needed conf_mode scripts without a need for reinitialization.

The dockerhub image is just an environment capable of generating the vyos image, it does not include any of the files needed to generate the image itself. These files are inside the vyos-build repository.

To clarify the hw-id tag. This is the only way VyOS scripts know what interface to give what name on bootup, as the boot-order of nics could be different on every reboot (potentially) vyos needs a way to identify the "correct" order of the nics when it boots. if you remove the hw-id tag from the interface the configuration script don't know what interface to give the configuration to, so you could potentially get nic-reordering on every single reboot.

What repository, and what errors? :)

I've added an extra bulletpoint that needs to be fixed in the comment prior to this one.

VyOS dont provide the packages upstream to anyone, and a package is only installed at image create time and never upgraded. And as the changelog have up to now newer been used i dont see the point of over-complicating this. This will only make it harder to make a release image as more unnecessary (as i would call it) steps are added to the process.

Yes, i'm aware of these modifiers. But the issue here is not to generate newer then the upstream, because we are the upstream. these changes are to make the version visible in our upstream packages. the current solution with manually versioning does not work because the Debian version is "never" incremented. (there could be hundreds of commits between each version increase..) and in the mean time it is quite hard to identify exactly what changes are made to the package in the image. for this we automatically change the version tag on build-time and adds the most resent git version tag and the number of commits since that tag visible in the upstream version tag. as for the "downstream" part of the version tag we out the git commit id and info about the "state" of the repo on build-time. those we also could identify if the package build is indeed the upstream package or a custom package by the user. :)
upstream version will be in the format of : <git-version-tag> - <commits from tag> and downstream version: -g<commit-id>(+<dirty>)? an example : 1.3dev0-4 -g1234567 and 1.3.0-0 -g1234567

"This is fine if used in conf_mode scripts that'll create it after that anyway" if the intention of the code was not to create the interdace this is not fine if you ask me. :)

thats correct @jjakob , when a mac is changed on a interface the ONLY place to find the original mac address for a interface is using the hw-id, this is because the kernel does not hold track of the original mac anywhere. for now on saving the config it reverts back to the original hw-id mac when the mac node is deleted witch should be quite fine to do. When the old boot interface mapping code is rewritten these pointers also need to match the new scripts. but thats another storry :)

Actually, specifying wireguard peer as a hostname only worked on initial setup. The reason for this is that the hostname is resolved only on initial startup of the wireguard tunnel. On boot the ip stack is not fully operational resulting in wireguard beeing unable to resolve hostnames. (But this avtually could depend of the execution time of the initialization scripts) .. a better alternative to this is to make a initialization script that is delay'd and then resolves the hostname and inserts the correct ip in wireguard when the router is fully booted. This could be created using a custom script called from the post-bootup script or something like that.