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

This can be mitigated by:

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

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.

@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.

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?

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.

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)

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:

Tested it right now, set interfaces bridge br0 member interface eth3.4 worked fine with latest current vyos-1x, so the next ISO should definitely have this fixed.

See T2427, the fix for that was merged today and will be in the next ISO build. I'll test that new ISO too to see if I catch any migration errors (I tested it just on a test VM without upgrading and I didn't see any VLAN errors, several configured VLANs seemed to work)
Edit: I see the error is for eth vif in a bridge, I didn't test that, just vif on ethernet and eth in a bridge. I'll test it today.

Just wanted to add an update on this, as of today May-6-2020

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

Why do we need to remove all addresses from the interface when it is disabled? That causes a commit error on dhcp:

vyos@vyos# set service dhcp-server disable 
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# delet service dhcp-server disable 
[edit]
vyos@vyos# commit
[ service dhcp-server ]
DHCP server configuration error!
None of configured DHCP subnets does not have appropriate
primary IP address on any broadcast interface.

@thomas-mangin there was a bug in PR #383 that prevented bond interfaces from coming up - it thought the members had addresses assigned, but they didn't. Something in my PR#384 fixed it - I'm not exactly sure what - probably assigning the intf['intf'] in get_intf_from_dict or fixing the _basename function. There is still a bug with IPv6 link-locals that worked fine before - I'll see if it's easy to track down, if not I'll open a new task for it.

@Viacheslav I confirmed the bug you have with assigning 'fe80::/64' when it shouldn't. It appered after https://github.com/vyos/vyos-1x/pull/383 - I'll investigate once my other PR gets merged and open a task for it. (note that it should add the fe80::(eui-64)/64 based on mac address by default and no-default-link-local did disable it before PR#383)

This is a result of a regression in unionfs-fuse, fixed in commit 93c2f9b, but not contained in the debian buster package v1.0. The naming convention for directories was changed from unionfs to unionfs-fuse, and then reverted, forgetting to revert the meta directory name. Consequently, bad things can happen for packages that had defined the meta directory consistent with the pre-v1.0 naming, for example, vyatta-cfg. Two fixes have been tested with initial success: (1) patch unionfs-fuse (2) change the meta directory name in vyatta-cfg. Either fix passes initial tests, although closer scrutiny is warranted, as it is a critical issue. The downside of (1) is the need to maintain an upstream or patched version of unionfs-fuse; the downside of (2) is that we are accommodating a regression, which will break again when/if the upstream package is available. Likely the quickest solution is preferred, as this issue is implicated in several recent bug reports.

Need to check again with 1.3, as may be solved by: https://phabricator.vyos.net/T1291