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.

I will look into the use case and see if I can think of something.

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.

@dmbaturin @c-po
Not sure why did we merge these PRs. The isc-dhcp-relay does require at least two interfaces to work. This was discussed in details in T1276 and T2408.
As result the latest documentation is inaccurate what could make users confused.

I again ran into a situation where it would be nice if create=False were the default, and if we could use the Interface class without creating the physical interface. The bridge member port configuration defaults were previously stored as a dict in interfaces-bridge.py, but as I added a method Interface.add_to_bridge() that all interfaces can call on themselves, I couldn't place the default port config into BridgeIf: when creating a bridge for the first time, the physical interface doesn't exist, but we need to get the member port default config in interfaces-bridge.py get_config() without creating the physical bridge interface (this should only happen in apply()). Thus I had to put it in util.get_bridge_member_config(). If I could call BridgeIf.get_member_config() when the physical interface doesn't exist without creating the physical interface, thet code could be moved from vyos.util into BridgeIf.

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.

How would the auto-detection work? Go through all the possible MTUs one by one? (a binary search would be way better) I'm not sure how long that would take for systems with lots of interfaces. We also need to then save this limitation somewhere permanent, and read it from the interface code, possibly a custom validator script (the shell completion can't be made dynamic). I guess this would be okay, depending on how much time it would take. The speed would depend on the interface driver. There could be drivers that are very slow, we couldn't test them and people would complain.

Please test using the latest rolling ISO at https://downloads.vyos.io/?dir=rolling/current/amd64 which has multiple fixes for interfaces included. Also, I still don't understand what the exact issue is. I have a similar configuration here and I have no issues with the image from 20200509.

Since the issue is resolved can this be closed?

The bug is produced because of deleted deprecated option in vtysh. Before FRR 7.3:

root@vyos:/home/vyos# vtysh -c "show ip community-list 10"
This config option is deprecated, and is scheduled for removal.
if you are using this please migrate to the below command.
'show bgp community-list <(1-500)|WORD> detail'
% Can't find community-list

Starting from 7.3:

root@vyos:/home/vyos# vtysh -c "show ip community-list 10"
% Unknown command: show ip community-list 10

In VyOS 1.2.5 the same bug.

All sounds good to me.

That build was given to me to test in #lobby by Thomas Mangin, so he may be able to tell you more about it if needed.

PR405 corrects this