@kroy AFAIK, intel drivers, KVM (VM performance and I/O), Kernel memory I/O etc.
Performace data can be recorded and replyed asewll. Looks like candidate for debug images as @c-po pointed out.

I guess I'd ask the question of whether we have any complaints of performance type issues that perf could pinpoint? I don't know if I've ever seen any of those kind of complaints in the circles I hang out in.

perf is a tool to gather performance and debug data on a running system with a deep insight into program functions etc. Since it will need a bunch of new libs within the system, I'd like to find out if there is the need for it or not.

This still needs some review and testing. @Merijn, thank you for the offer; testing will be much appreciated, once PRs are merged.

@dmbaturin did you find time to check the pull requests? Checked with latest crux build and the issue still exists.
I can test this if needed.

This is dependent on T1260, which will need to be backported.

This never made it into VyOS 1.2.1, so it will need to be backported to Crux, either 1.2.4 or 1.2.5, depending on schedule.

This will need several related commits, testing, before being backported.

Hey, the deleted comment I made above was incorrect, this works on 1.2 rolling, it is still broken on 1.3. Sorry for the confusion.

Need run increment first.

Crux needs a backport of show_dhcp.py from current, I fixed this in current

In T1376#38816, @zsdc wrote:

In T1416#38750, @dongjunbo wrote:

Seem like static counting still not right

@dongjunbo, show please the configuration of this router so we could check why gcdomestic pool does not count correctly.

Dear， Developers
Seem like the bug still there in vyos 1.2.3 release version

PR166 should fix this.

backported to 1.2.4

Commands used for testing on VyOS 1.2.3 (also tests the config migration):

It looks like the domain and search are now working (and not showing the DHCP one as expected, so that is fixed too), but the DHCP nameservers are still there:

Frankly, I can see why FRR doesn't want it to be modifiable at runtime. If you are decreasing the number, it would force a big routing table rebuild, and tracking whether the user increased or decreased it to decide if command should be allowed or not is more trouble than it's worth.

It may be supported but the syntax in the Pull-request is wrong and does not work for FRR, it needs to be adjusted.

I just updated the equuleus branches. Please test tomorrows rolling release as it should have the fixes.

So just an update, this issue is still present on more recent VyOS 1.3:

It looks like this is indeed fixed now!

Just a note, I updated my docs above cause they were missing the OSPF+OSPFv3 portion of the interface config that enabled BFD :)

The original client-id has been cherry-picked into crux, but the vendor-class commands are not backportable since they rely on the new interface scripts.

Also in crux now.

Cherr-picked into crux.

This is related/a duplicate of T1744

The replacement of special characters with backslash decimal happened on upgrade from 1.2.0-rc11 to 1.2.0-rolling+201906231514.