I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 16 2020
May 14 2020
May 12 2020
I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
No Problem - nice to see races for bugfixes
May 11 2020
Thank you for the good explanation in the issue!
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.
May 10 2020
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.
The inconsitency of the naming is b/c the default routing table naming is inconsitent, too - thus it makes it consitent again :)
May 8 2020
May 6 2020
New commands added:
May 4 2020
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.
This has been completely rewritte in Python/XML. Please reopen if this is still a problem - and if so what do you think should be the "real" rendered configuration.
I suggest adding a "validate" function to vyos.validate. We should determine the hypervisor used and if a setting is allowed on that hypervisor or not. Thus we can throw an appropriate erorr message by raise ConfigError() in the Python file changing the interface setting. This would be the cleanest way then the "false" setting never reaches the configuration backend at all.
May 3 2020
Sure it can (was in the initial ifconfig.py rewrite IIRC)
May 2 2020
May 1 2020
vyos@vyos:~$ monitor traceroute vrf red 1.1.1.1
The following adds support into the XML generation but I have no clue about vyatta-cfg how those files get executed.
Presumably a val_help line in the op-mode node.def, too
Tested good - migrating traceroute now