Actually I think this is a result of T2434 since the source interface is bond1, so I'm closing this again. My apologies.

@jjakob This doesn't appear to have been fixed in VyOS 1.3-rolling-202005130117

Should we trap the signal in vash, set an env value and use it with vyos?

I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6

I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6

No Problem - nice to see races for bugfixes

@c-po beat me to it by 1 minute - I was wondering why my PR wouldn't merge. I apologise for the error.

Right - that should be 'addresses-add' - the keys are different from other interfaces, and I don't have any tunnels configured to test. I'll make a patch.

This was a breaking change

Ducumentation at https://docs.vyos.io/en/latest/interfaces/ethernet.html#cfgcmd-set-interfaces-ethernet-interface-ipv6-address-autoconf
is inaccurate, forwarding is not disabled if autoconf is set. It probably refers to behavior before a rewrite was done and should be updated.

Thank you for the good explanation in the issue!

Okay the problem here is that FRR stores the network as fe::/64 and not as fe::0/64 which was specified on the VyOS commandline. Thus the grep command used when deleting the route does not find the proper FRR entry and gives that error.

https://github.com/vyos/vyos-1x/pull/407

Replicated the issue, I can't get a autoconf address just by setting ipv6 address autoconf. The problem is accept_ra=1, which means to not accept RAs if forwarding=1 (which it is, as we're a router).
Running sudo sh -c echo 2 > /proc/sys/net/ipv6/conf/br2/accept_ra' will make it accept RAs. We must fix the issue by also doing this in the interface scripts.

My vyos2 virtual machine can only get a 128 prefix address without routing. What's the matter?

Let me see if it works from the vyos2 virtual machine

why does DHCPv6 provide an address with a prefix of 128?

The configuration mode executes show service router advert result:

@dmbaturin numeric breaks with --non-negative 0 (should be true)

$ /usr/libexec/vyos/validators/numeric --non-negative 0
Fatal error: exception Invalid_argument("compare: abstract value")

The virtual machine takes DHCPv6 (over opnsense firewall virtual machine) directly from the main route of vyos1, but after waiting for a while, it can only get the suffix with the prefix of 128 that cannot be routed.

Do you have service router-advert set on the interface that you want to have the fc00:470:f1cd:101::/64 on, and does it have managed-flag set? For a client to use DHCPv6, it must first get a RA with managed flag, only then it'll try DHCPv6. The interface must not have no-default-link-local, because RA and DHCPv6 depend on a link-local to work.
What does your show interfaces and show service router-advert show protocols config look like, and also run show ipv6 route and run show dhcpv6 server leases?
I'm running 202005090117 as well and I have no problem with DHCPv6, so the problem must be with your configuration.

https://github.com/vyos/vyos-opennhrp/pull/2
https://github.com/vyos/vyos-nhrp/pull/4

I did something similar, including generating the changelog with name/email and releasing, here: https://github.com/jjakob/vyos-build/commit/8353f1653be76c5b200b9357ebb9d76a84d3139c
The version name generated is also one I arrived at after some consulting, what confused me the most was what the precedence of the special characters is, that wasn't very well documented in debian's docs - elbandi's suggestions are all correct and very good.

For _stable_ release build, you need a fixed point in every vyos/vyatta package (vyos-1x=1.3.1, vyos-netplug=1.2.9.2-3, vyos-opennhrp=0.14.1-1, etc), so you have to release every package, something like 'Oh, this package is in this point stable enought for a stable release', and the stable iso contains this stable packages. But the development doesnt stop, some packages receive new fetaures. Until stable packages are waiting for each other, need a versioning for daily snapshot. for that, the commit count based versioning is good.

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.

That could als help on debugging like adding vyos-config-debug option or as I like on my hosts, vga=773 when debugging and checking for config migration issues.

In regards to 1) I do not remember why I added it there as FRR seems to accept that kind of routes - but its actually a warning only no real error.

i would leave the items in changelog, just every changelog items have git tag. if there is a new release (=new _stable_ release iso), make a new changelog item + git tag.
and for the development packages use your versioning: 1.3.0-17+dev<commitcountfromtag>-git<commit-id>
anyway, there is a "gbp dch" command can generate entries from Git commit messages. you you can fill the "dev" changelog entries with real commit messages. you can set the versionstring too.

The inconsitency of the naming is b/c the default routing table naming is inconsitent, too - thus it makes it consitent again :)

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

If enable is not clear as a name to say that it adds the feature to the class, it is a class decorator, then please suggest a better name.

Since PR#376 I'm getting nothing logged into the file set by vyos.log.debug at all:

Works for me nicely. Thanks.

Suggested patch here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:T2049.patch

Test problem solved

you can use '+' and '~' chars in versions. plus gives newer version (1.2.3-4-5+foo32 > 1.2.3-4-5 ) but less than the new upstream (1.2.3-4-6 > 1.2.3-4-5+foo32), tilde gives older version (1.2.3-4-5~foo-2 < 1.2.3-4-5 )
i always use + for my own builds, thats gives me newer package version than ubuntu/debian version.

I don't see any problem on user receive message telling him MTU is not accepted by OS when his commit
On Juniper it is very common case

I have implemented a "validator program" which is an entry point which will locate a named python program and run it. It uses the import mechanism of python at startup so the setup time is very high.

I raised this with the team and the idea of auto-detection does not get much support, which is fine, I just wanted to make sure I was doing the right thing. So I will finish this patch which will prevent some failure case and try to make the error message friendlier. Also, can look at where in the chain of change the MTU is performed to see if it can be rolled back.

Hmm, another thing - how about hot-pluggable ethernet cards? They could be USB, or in the enterprise world servers that support PCIe hot-plug could have ethernet cards swapped on-the-fly. I'm thinking the MTU detector script would need to be executed via udev rules on 'add' events.

Comparison of the numeric validator:

$ time sudo sh -c 'for ((n=0;n<1000;n++)); do /usr/libexec/vyos/validators/numeric 1; done'

New tests with the OCaml validate-value (same machine as above)

$ time sudo sh -c 'for ((n=0;n<1000;n++)); do ipaddrcheck --is-any-net "192.0.2.1/24"; done'

My suggestion: if you do a MTU suggestor/validation should be a tool optional outsite configure

This is an issue with the new OCaml validator 29dee3abb55d0f0c6b91b311f30521b45d7e46b6 @dmbaturin

Reproduced with 1.3-rolling-202005090117

I see the XML format did use to have a way to set 'type', but this was regarded as unimportant and removed. It's very important for the bash completion scripts and needs to be added back.

Thanks to @thomas-mangin there is now a common function to parse common interface options in configdict.intf_to_dict() and other common functions to get (configtree.add_to_dict()), verify and apply (ifconfig-vlan.py) vif and vif-s/vif-c configuration which simplifies things a lot. It can be used by other interfaces that support those options (all L2 interfaces, and tunnels in L2 mode). Those functions are already used by bonding, bridge, ethernet, pseudo-ethernet and wireless, it wouldn't be much work to add them to other L2-capable interfaces.