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

@maznu I think this will be the default only after BGP switches to a new XML/python format.
https://phabricator.vyos.net/T2174

The good news is that this can be fixed with:

To reproduce it in a test lab.
R1 Originate 1000 prefixes
R2 import 1000 and export 40 prefixes to R3
R3 prefix-limit 40 prefixes.

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

It appears you are sending a redundant 'set' within the path itself.

https://github.com/vycontrol/vycontrol/issues/27

ack - I will change this to make sure it is safe !

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.

It seems to be reading the output of something that thinks it's talking to a VT100 terminal.

Example of output containing control characters.

@fetzerms I believe this is resolved by the fix in T1899, which will be in the next rolling release.

@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

@Gislaved, I have just tested it on the KVM (proxmox) with VirtIO and I coudn't reproduce it. It works with exactly the same defects as I mentioned in my previous message. Tested on the both LTS and 1.3-rolling-202005031216.

@brussell @Viacheslav @dmbaturin @zsdc
FRR devs agree to change the default behavior in 7.4
so we need to prepare change on our side and also document that change in FRR docs

Would love to see this resolved — a large (but reasonable) configuration doing IRR-based filtering from BGP peers took 9 hours to boot up.

It is already in the manual. Not at the Troubleshooting section, but at Configuration Overview.
https://docs.vyos.io/en/latest/configuration-overview.html#comment

That was done.

In T2404#62721, @jjakob wrote:

@c-po is it possible to detect the exact networking setup used on the host? If not, I don't think that'll do any good, because the hypervisor is just that - a hypervisor. There can be many different types of networking. Like in this case, Openstack's SDN supports a lower MTU than a bridged or NATed connection with the same hypervisor would. The only reliable way is to detect the max MTU in some way (the kernel/device driver must know this, the question how can we read it) - the first step is to not touch the default MTU if the user doesn't set it.

@c-po is it possible to detect the exact networking setup used on the host? If not, I don't think that'll do any good, because the hypervisor is just that - a hypervisor. There can be many different types of networking. Like in this case, Openstack's SDN supports a lower MTU than a bridged or NATed connection with the same hypervisor would. The only reliable way is to detect the max MTU in some way (the kernel/device driver must know this, the question how can we read it) - the first step is to not touch the default MTU if the user doesn't set it.

Wireless AP completely rewritten. If issue reappears please reopen or file a new bug.

Forum says issue is fixed. Also WWAN underwent a major rewrite - should be all good now.

@MikeLupe Are you using a custom dyndns provider/script? It ifs compatible with the dyndns2 "API" this is already possible using the "custom" dns dynamic service.