@plett VyOS 1.4 now does an automatic fallback to the 1.3 behavior which used FRR 7.3 until we decide how to handle this, w.g. by adding a new CLI option which is added by a migration script to keep older systems running "as is" when upgrading.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Feb 16 2021
Yeah.. I don't think it's a timeout issue really.. because of this:
In T2100#72560, @jestabro wrote:FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.
@Viacheslav , good point, and unfortunately, that's not an exact science: cf. T2252, wherein the timeout was raised to 10 minutes, the time of the timeout reported above.
It possible nginx limitation, need to change/set/tunning some timeouts.
@pasik this is not a known issue, and your report is much appreciated. I have not drilled down into the problem yet; any debugging that you have a chance to do is welcome !
Any comments here? Is this a known issue/limitation? I can look into the internals and do some debugging if this should be working in the current state..
The translation is working properly now but it is not showing in the command output:
Maybe we should consider using a better proxy server to complete the dhcpv6 agent
Feb 15 2021
Somehow this was lost in translation in my git repo....
Nackported to 1.3 equuleus
Yes, I very much like this, and is what I am imaging with 3., above.
With this new information I see little to none reason to keep the key_mangling() workaround. If we manage to transform all nodes into "proper" syntax we can one day drop it.
PR https://github.com/vyos/vyatta-cfg-firewall/pull/20 is still pending to clean up the following log entry:
@c-po this is an excellent idea, and a useful reference for the bracket notation; this will need a bit of design of how best to slice the problem:
- keeping key_mangling but excluding on tag nodes
- removing key_mangling completely
- removing on a case by case basis with the existing argument to get_config_dict()
XML for policy access|access6|prefix|prefix6|community list
Feb 14 2021
In the new xml/py rewrite, do they disapear if you rerun the bgp configurator script? Eg. Can we execute frr-reload twice as a workaround?
This actually feels like an FRR bug as this still occurs with the new XML/Python rewrite
This is fixed in 1.4 as proper input validation happens.
Currently this requires BFD support to be added to frr-reload
Implemented/fixed for VyOS 1.4
Issue no longer persists in VyOS 1.4. Tested using: 1.4-rolling-20210214