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

I forget - I did not observe any disability in router behavior. At least with simple configuration that I tested.
Observed messages may be a bit worrying for users at the very beginning of using VyOS.

This can be mitigated by:

1. add to ALL ipv4 peers "address-family ipv4-unicast" set

I confirm that this can be mitigated by:

1. add to ALL ipv4 peers "address-family ipv4-unicast" set

set protocols bgp xxxxxx neighbor x.x.x.x address-family ipv4-unicast

2. disable default ipv4 peering

set protocols bgp xxxxxx parameters default no-ipv4-unicast

Okay @jjakob, thanks for pinpointing the concern: (quoting from above) 'IMO this should not read config.boot, but return an empty config' --- this is a reasonable position; I will test this modification, along with a consistent change to get_config_dict, and we can discuss.

I've fixed the service files for isc-dhcp (in T2438), other service files still ned to be moved to Type=forking or a suitable type (notify/dbus...) to fix their behavior, unless they already are.

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

After relevant tests, it is highly suspected that the configuration dependency problem can be solved by manually loading the following instructions:

Because the problem is that in the process of loading config.boot after the vyos system is restarted, the configuration dependency of the sequential application configuration is not considered, so the accurate error reporting information cannot be provided. You can use the above configuration structure to reproduce.

Due to configuration dependency, accurate error information cannot be provided, but there is no problem using the following order:

202005051136 has multiple issues, there are multiple PRs waiting to be applied on vyos-1x to fix them. You didn't append the exact error messages.

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

@jjakob it does nothing about the boot case but it would be much easier to add it to that code than what we do ATM.

It seems that github has special rules for the .github file and that no PR can be done for it:
https://github.com/thomas-mangin/vyos-1x/blob/T2436/.github/workflows/pythonapp.yml

@thomas-mangin I saw that and I think it's a good idea, to even make it into a common library we could use from all interface scripts. Does it work correctly on boot however? I see it uses exactly the same config.py methods that I'm talking about above that would return incorrect values on boot. I didn't try it but I'm highly suspecting it doesn't.

I would also suggest doing the same using github actions so that on push to your local repository to get a warning from github.

Why do we need to remove all addresses from the interface when it is disabled?

Can I throw https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/interfaces-tunnel.py#L32 into the mix?

The fix for the error for openvpn is already waiting in PR since yesterday, fix for pseudo-ethernet and vxlan will be ready right now.

Wouldn't it be better to add it to the vyos-1x Makefile so we could test it ourselves, before committing, making a PR, it being merged, and only then figuring out it's a problem?

I couldn't reproduce this on my own build I made yesterday, I'll try it with the above ISO

In T2409#62999, @jestabro wrote:

I suggest you ignore T2030 for a moment --- I recall discussing that issue with the author, but I think the code comments are leading you astray ... we can return to that later.

You appear to equate active with the saved config file, in your first comment above;

No, I am not equating the active config with the saved config file.

that will be the case, after the boot commit completes, which begs the question: what do mean 'at boot' --- at some point during the boot process (in vyos-router), a config session is initialized, the config file (or a default if first boot after install) is loaded, and committed. Between load and commit during boot, there is no active of effective config defined, nor can you query it without error, as it is meaningless; on the other hand, between load and commit, the proposed config (showConfig --show-working-only) is what you would expect; after commit, one has active/effective == proposed, assuming no error.

This is exactly what I had in mind, but maybe my terminology was inaccurate: between load and the end of the commit, during the commit, we have the proposed config, which can be queried with get_value() etc., and the effective config, which can be queried with get_effective_value() etc.
Currently the interface scripts take the proposed config and apply it, but there are some places where they already compare it with effective config, to see what the differences are and what to apply.
For example:
https://github.com/vyos/vyos-1x/blob/current/python/vyos/configdict.py#L299-L315
This takes the difference between get_values and get_effective values to see what addresses to remove.

I suggest you ignore T2030 for a moment --- I recall discussing that issue with the author, but I think the code comments are leading you astray ... we can return to that later.

How this can be implemented in practice was tested with https://github.com/thomas-mangin/vyos-extra

• the program can be installed using pip/setuptools and the "vyosextra.main:main" entry point, generating a "vyos" program.
• the "release" program in the root folder generates a self-contained executable (using the builtin python3 zipapp library) which can be place before in the path, taking precedence over the installed version.
• each feature "vyos ssh", "vyos update" is a single program and could be installed independently using other entry points
• dropping a program in the folder automatically registers it to the main "vyos" program, each program has a "def main()" with a docstring used for the "-h"
• the assets in the data folder are converted into python dict and used when the program is a zipapp.

Changing this to

chown nobody:vyattacfg /config/dhcpd.leases*; \
chmod 664 /config/dhcpd.leases*; \

(note the *)
has fixed the error with dhcpd. The same needs to be done to dhcpv6.

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