I would be wary of including it in Crux, since it's a behaviour change.

These are default VyOS installations without any modifications other than to the running configuration. During these recordings I set IP address, duplex, and speed on eth0, set a static route, hostname, and ntp, time, and dhcp server configurations. While doing so, I used ? to enumerate possible configuration paths and [tab] for CLI completion to hopefully illuminate the latency in these operations.

https://github.com/vyos/vyatta-ipv6-rtradv/commit/2c543f7f369f9429e7dad89bb7bb9f9dec823856

Thank you, @ekim!
What exactly you were doing at the moment of this log record? I see a lot of scripts, which are almost permanently do something in the system. Is it possible that this system contains some custom scripts (in /config/scripts folder, for example)?
If yes, you should check the schedule of execution, and requirements of modification for 1.2 version command syntax.

Please backport to Crux.

This is already fixed in the latest rolling images (equuleus).

Fixed for rolling release.
https://github.com/vyos/vyos-1x/commit/016524841da12b68468468cf8f4947b82213ffcd

I created a pull request to fix it. @guertinf has already test the fix

Oh I just noticed: "set src" in a route-mao only works for ipv4 addresses in vyos, according to a friend FRR does support ipv6 though...

I'm no vyos expert but something along these lines should do it:
https://github.com/vyos/vyatta-cfg-quagga/pull/30

Thanks! Here you go!

Hello, @ekim! I see now. This is more looks like the waiting due to I/O. Do, please, the next:

1. Run sudo atop -w /tmp/atop-mon.log -a 5 60 in dedicated terminal.
2. Try to work several minutes in the terminal. It must freezing at this moment, otherwise, collected test data will be wrong.
3. Wait until atop finish its work (~ 5 min from the start).
4. Copy the file /tmp/atop-mon.log from the router and send to us for analysis.

Same issue present in 1.3

Neither have configurations on them. However, CLI response time when a configuration is loaded is even slower on 1.2.1-s2. Of course, no perceptible impact on 1.1.8.

A check is already present when configuring the firewall name.

As long as its allowed but not working its a bug.. :)

this commit broke it: https://phabricator.vyos.net/rVYOSONEXd76798085ea8a77ffca3c6fbb6df74fc3121c333
There may be more scripts affected.

Issue present in the 1.2.2 ISO, too

@ekim, could you make a screen record with this CLI delay?

Today I experienced the same asynchronity in the OSPFv3 subsystem

https://github.com/vyos/vyos-1x/commit/65b2f36a77f311a207b8e5406d222f4dbef177cf

Thanks, the trick was adding some link-local adresses.

The protocols BGP being missing, I believe is the bug in https://phabricator.vyos.net/T1490 and actively being worked on.

This is frr show run, immediately after an upgrade to 1.2.1

I tested the following so far successful:

Neither the CPU or memory load ever exceeds 0.5% utilization while idling. I haven't tested whether throughput or control plane timings have been impacted.

Hello, @ekim!
Such a significant increase of boot time with the same configuration is very strange, but still possible - even small changes can easily cause such behavior if you have a huge or some specific configuration. But what is more strange - CLI response time. Regardless of configuration, CLI should work without visible delays, except for autocompleting or commit operations.
Could you check the current load of the host at that moment, when CLI is slow? We must be sure that the system is not overloaded.

The issue can be reproduced using the sanitized configuration below:

Unfortunately the configuration is incomplete. Can you either add the missing parts or you can PM your real configuration if this works for you, or use the show configuration commands | strip-private command to remove any sensitive stuff.

@ekim First of all, a quick fix for your situation with next-hop: add { } after the next-hop that is missing it. I.e.:

Can't reproduce, but I experience a different issue - Nameservers are not propagated into resolv.conf

Unfortunately this is not 100% correct, the intel drivers are pinned to a specific version. Only vyos-wireguard, vyos-accel-ppp are using git HEAD revision from their individual repos.

and always download the latest upstream driver

i think that out-of-tree drivers also needs to be under the same control as modules and the kernel

I only see some minor problems, but in general I like the idea very much!

Putting the migration script on hold until I can get sample configs for "service dhcp6-server static-mapping identifier ..." and related host entries in /etc/dhcp/dhcpdv6.conf from an old vyos version with the old vyatta-cfg-dhcp-server scripts.
In particular if it was possible to set quoted strings as identifier which would be set unchanged in dhcpd6.conf, this would necessitate detecting whether the identifier was a quoted string or not, and converting the string to hex. If it wasn't possible to set quoted strings the migration script is not necessary.

I am confirming that the problem is not reproducing in the 2.0.17. We should upgrade keepalived distribution.

Since this changed dhcp6.client-id to only accept colon-separated hex lists, configs that still have the strings will fail to apply, leading to nonworking configs.
Should we bump the dhcp-server vyatta-config-version and write a migration script?
Shouldn't there be a separate dhcpv6-server/relay vyatta-config-version? Perhaps the migration script could add those.

protocols {

bgp 132394 {
    address-family {
        ipv4-unicast {
            network 0.0.0.0/0 {
            }
            network 103.20.20.0/24 {
            }
            network 103.232.159.0/24 {
            }
            network 103.232.216.0/23 {
            }
            network 202.0.150.0/24 {
            }
        }
        ipv6-unicast {
            network 2402:7b80::/32 {
            }
        }
    }
    maximum-paths {
        ibgp 6
    }
    neighbor 103.232.216.229 {
        address-family {
            ipv4-unicast {
                nexthop-self
                route-map {
                    export DENY-EBGP-IBGP
                }
                soft-reconfiguration {
                    inbound
                }
            }
        }
        advertisement-interval 1
        remote-as 132394
        update-source 103.232.216.226
    }
    neighbor 103.232.216.230 {
        address-family {
            ipv4-unicast {
                nexthop-self
                route-map {
                    export DENY-EBGP-IBGP
                }
                soft-reconfiguration {
                    inbound
                }
            }
        }
        advertisement-interval 1
        remote-as 132394
        update-source lo
    }
    neighbor 203.20.64.242 {
        address-family {
            ipv4-unicast {
                prefix-list {
                    export BGP-OUT
                }
                route-map {
                    export AS132394-OUT
                    import AS132394-IN
                }
                soft-reconfiguration {
                    inbound
                }
            }
        }
        description "TRANSIT: VIRTUALNODE (AS137273)"
        ebgp-multihop 2
        remote-as 137273
        timers {
            holdtime 30
            keepalive 10
        }
        update-source 103.232.216.226
    }
    parameters {
        default {
            local-pref 125
        }
        log-neighbor-changes
        router-id 103.232.216.226
        scan-time 5
    }
    timers {
        holdtime 10
        keepalive 3
    }
}

Trying to figure out how to do this via xml. Seems like it generates the .def files from the xml Does it require rebuilding the whole image to test?

@zx2c4 thanks for clarification. But why does OSPFv2 work as it uses multicast too if I remember correctly.

Yes. It explicitly doesn't do it.