Perfect, thanks

Sorry. Yep. Can confirm, problem fixed.

Here is some more testing. Currently on FRR 7.5:

Currently, vyos-configd will explicitly report ConfigError to the console; however, non-fatal warnings or information will not be reported. An example of a non-fatal warning is:

SolarFlare modules present in the kernel for 1.3 and 1.4

vyos@vyos:~$ sudo modinfo sfc
filename:       /lib/modules/5.10.14-amd64-vyos/kernel/drivers/net/ethernet/sfc/sfc.ko
license:        GPL
description:    Solarflare network driver
author:         Solarflare Communications and Michael Brown <mbrown@fensystems.co.uk>
alias:          pci:v00001924d00001B03sv*sd*bc*sc*i*
alias:          pci:v00001924d00000B03sv*sd*bc*sc*i*
alias:          pci:v00001924d00001A03sv*sd*bc*sc*i*
alias:          pci:v00001924d00000A03sv*sd*bc*sc*i*
alias:          pci:v00001924d00001923sv*sd*bc*sc*i*
alias:          pci:v00001924d00000923sv*sd*bc*sc*i*
alias:          pci:v00001924d00001903sv*sd*bc*sc*i*
alias:          pci:v00001924d00000903sv*sd*bc*sc*i*
alias:          pci:v00001924d00000813sv*sd*bc*sc*i*
alias:          pci:v00001924d00000803sv*sd*bc*sc*i*
alias:          pci:v000010EEd00001100sv*sd*bc*sc*i*
alias:          pci:v000010EEd00000100sv*sd*bc*sc*i*
depends:        mdio
retpoline:      Y
intree:         Y
name:           sfc
vermagic:       5.10.14-amd64-vyos SMP mod_unload modversions 
parm:           vf_max_tx_channels:Limit the number of TX channels VFs can use (uint)
parm:           max_vfs:Reduce the number of VFs initialized by the driver (int)
parm:           mcdi_logging_default:Enable MCDI logging on newly-probed functions (bool)
parm:           rx_refill_threshold:RX descriptor ring refill threshold (%) (uint)
parm:           irq_adapt_low_thresh:Threshold score for reducing IRQ moderation (uint)
parm:           irq_adapt_high_thresh:Threshold score for increasing IRQ moderation (uint)
parm:           interrupt_mode:Interrupt mode (0=>MSIX 1=>MSI 2=>legacy) (uint)
parm:           rss_cpus:Number of CPUs to use for Receive-Side Scaling (uint)
parm:           efx_separate_tx_channels:Use separate channels for TX and RX (bool)
parm:           phy_flash_cfg:Set PHYs into reflash mode initially (bool)
parm:           debug:Bitmapped debugging message enable value (uint)

As a solution proposed to use TTL by default equivalent 16, but also add the possibility to change it via VyOS CLI

Tried to mess around/instrument https://github.com/vyos/vyatta-cfg/blob/current/src/cnode/cnode-algorithm.cpp#L924,
ended up loosing the active config and /opt/vyatta/config/active becoming empty.

Looks good on 1.4-rolling-202102162107 (including migration from self-built 1.2.0-rolling+202102162120).

It seems that the stall happens in ConfigSession.show_config() which calls /bin/cli-shell-api showConfig.

@c-po That seemed to more than double my RX!

@mathiashedberg could you try and enable RPS set interfaces ethernet eth0 offload rps and see if this does any good on utilisation / drop rate? I had a similar issue with a PPPoE link which behaved super bad under preasure.

So after a week of running, and comparing to performance with the LTS, i know that something is wrong.

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

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

Somehow this was lost in translation in my git repo....

Nackported to 1.3 equuleus

PR https://github.com/vyos/vyos-build/pull/146

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:

1. keeping key_mangling but excluding on tag nodes
2. removing key_mangling completely
3. removing on a case by case basis with the existing argument to get_config_dict()

XML for policy access|access6|prefix|prefix6|community list

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