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

Still TODO: apply STP settings when re-adding interface to bridge from interface scripts, currently the interface loses configured STP settings, but is at least readded to the bridge.

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

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

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

Personally I don't understand the insistence on keeping everything Python - in some cases, it is simply much better to use a more suitable language. A simple C program is IMO simpler and more KISS than a python daemon with a listening socket with clients connecting to it via UDP. You're invoking several layers of the OS (networking, process management, sockets) that are completely unnecessary in a simple "is this value OK?" program. I don't like convoluted solutions to solve a simple problem.

@jjakob I was going to offer to do so this week if people agreed to give me a chance to show good it could be.

@thomas-mangin if you can demonstrate your idea implementing the actual validator code would be close performance-wise to the old shell/C validators, I would be on board with it. But personally I like shell and C better :)

Using shell scripts would be a step back. The biggest part of the python script is the parsing of the vyos code. That's why I am suggesting that vyos command should be sent to a python daemon.
We can connect to it using IPC, and this can be done via a small C wrapper (or even directly in the caller's code to not even fork).

vyos@vyos# time bash -c ""

It's due to Python startup time. Validation of every config node requires a full startup of Python. It would be better to if the validators were shell scripts or C programs, as they were before, the load time is very small :) I think this is also a part of the significant difference in boot and commit times between 1.2 and 1.3.

I tried to add the prototype policy with XML.
https://github.com/sever-sever/vyos-1x/blob/policy-prefix/interface-definitions/policy-prefix-list.xml.in
Speed of validators "<validator name="ip-prefix"/>" very slow.

I was also wondering if we should attempt an auto-detection of MTU on boot and save the result? This is why I was asking if this was the right approach.

03:42:04  DEBUG - Traceback (most recent call last):
03:42:04  DEBUG -   File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 810, in <module>
03:42:04  DEBUG -     verify(c)
03:42:04  DEBUG -   File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 621, in verify
03:42:04  DEBUG -     verify_vlan_config(wifi)
03:42:04  DEBUG -   File "/usr/lib/python3/dist-packages/vyos/ifconfig_vlan.py", line 155, in verify_vlan_config
03:42:04  DEBUG -     for vif in config['vif'].values():
03:42:04  DEBUG - AttributeError: 'list' object has no attribute 'values'
03:42:04  DEBUG - 
03:42:04  DEBUG - 
03:42:04  DEBUG - 
03:42:04  DEBUG - [[interfaces wireless wlan10]] failed
03:42:04  DEBUG - Commit failed

Forgot to migrate other interfaces to use the new functions. Will prepare a new PR.

great work @thomas-mangin I was reading your code

Correct me if I'm wrong, I haven't tried it in practice, but the commits that fixed T2030 would seem to support my understanding.

@jestabro so get_config_dict(effective=True) will return an empty config dict on boot? AFAIK by reading config.py, it will be the same as get_config_dict(effective=False), so the diff between them will return 0 differences, thus nothing to apply, even though there's everything to apply (as it's a first commit on boot).

for example: an error in apply() raises ApplyError. in main, we catch the ApplyError and re-run the whole get_config, verify, apply chain but with effective config instead of session config (for example by get_config_dict, then comparing the old and new config dicts, we can kill two birds with one stone: get a revert function, and have a granular apply logic that only applies changed settings - though I'm not sure that can work with the way the effective config is obtained right now, AFAIK on boot both are identical so it wouldn't work: see T2409)

@thomas-mangin seems mostly fine via quick glance. Only the max_mtu is imo wrong - the device may support jumbo frames. If we limit upper MTU to 1500 we'll prevent the user from using jumbo frames if he chooses to. I can't think of a good way to solve this whole issue within the confines of the current get_config/verify/apply separation. We simply can't verify if the MTU is allowed for the hardware without trying to apply it. Some network cards don't support jumbo frames, some do, with various upper limits: baby giant, super jumbo,... (https://en.wikipedia.org/wiki/Jumbo_frame)

It appears the patch doesn't fully account for all possible characters:

Hardware vendor: Red Hat
Hardware model: OpenStack Compute
MTU should be max 1450

Not sure if this is the right approach or not. Feedback welcomed.

New commands added:

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