The syntax was changed. VyOS 1.3-rolling-202007270117
I don't find "tsm" option

PBR present for vti, VyOS 1.3-rolling-202007270117

Pim implemented in T1729 and present int the current rolling release.

Well, does it not work, or was it removed upstream? Can we probably migrate it?

https://www.tucny.com/Home/dscp-tos

This feature request will be closed because the community does not agree to the replacement

In T2736#71448, @Viacheslav wrote:

https://github.com/aria2/aria2/issues

720 issues, one of them https://github.com/aria2/aria2/issues/1549

Sorry, but I also -1.

720 issues, one of them https://github.com/aria2/aria2/issues/1549

So these values don't work. VyOS 1.3-rolling-202007270117

set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp reliability
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp throughput 
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp lowdelay
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp priority
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp immediate
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp flash
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp flash-override
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp critical
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp internet
set traffic-policy shaper SHAPE class 79 match lowdelay ip dscp network

Of course, even if vyos does not support it or the community does not agree with it, it is not impossible to upgrade. I usually use SFTP to upload to the router to perform the local upgrade after downloading from the computer. Therefore, the current download tool can be modified and replaced selectively. This is only to explore the possibility

You may be mistaken. I'm right. If the server supports downloading and using breakpoint continuation protocol (HTTP range download), then aria2c can make it work, and breakpoint continuation has certain advantages, that is, in case of abnormal interruption, it can restart the download from the last interrupted location, instead of downloading from the beginning.. Moreover, the multi-threaded download function of aria2c may improve the efficiency and speed of downloading

-1 as well
As an additional tool I think it's ok but other than that there is no reason for that too.

You always say ‚if the server supports it‘s thats the main reason I do not want to add it - as it has a peer dependency which is bad times two. That counts as an additional -1 to me

The main consideration is that curl and WGet do not support breakpoint continuation function and concurrent download, while aria2 is a professional Downloader, which fully supports these functions. Of course, if the server supports breakpoint continuation, it can work well. This paper discusses the possibility of using aria2c for breakpoint continuation

I have to say i agree with @c-po, i see no real reason for changing this. But it could be added as an optional executable but not changing our internal tools to use it. -1

http://aria2.github.io/

@c-po In my personal opinion, it has more advantages than curl and wget. Because it can adapt to slow network (usually international communication is not particularly ideal period or area).

@c-po arai2c is the most frequently used download software in my computer. In fact, it is a command-line operating program. Under normal circumstances, aria2c has a high recognition among its users, even known as Linux's high-speed download software. It uses thread technology to download, transfers files in blocks, and supports disconnection and reconnection That is to say, as long as the server that downloads the file supports it, then aria2c can achieve breakpoint retransmission, that is, it can resume downloading from the last interrupted location without starting from the beginning.

I see no valid reason why to replace a known to be good piece of software just to replace it with something more or less fancy/doubtfull.

Can we consider using aria2c instead of curl to support disconnection and reconnection and parallel download?

As this is now handled via a generic implementation after the interface re-rewrite this can be closed

We use curl over wget on image upgrade process.

@Tiberius share your configuration and steps for reproducing.

This is an FRR limitation.
FRR allows you only to delete the comm-list.

Command was deprecated.

reset dhcp server lease ip <x.x.x.x.>

@hagbard Can you check it with the latest rolling?

EveNG lab tests have shown its not working as expected (yet)

I'll mark it as resolved. Reopen it if necessary.

Fixed, VyOS 1.3-rolling-202007270117

I'll mark it as resolved.
Reopen it if necessary.

PR https://github.com/vyos/vyos-1x/pull/519

We can close it.

I don't see this behavior in VyOS 1.3-rolling-202007270117

It seems in the FRR part of commands not working.

This fix remains an open discussion with @zsdc and @Dmitry

Thanks - added a note to the docs.

Ref: https://lists.zx2c4.com/pipermail/wireguard/2018-December/003704.html

Thanks for clarification! That exclusion could indeed be added to the config scripts would would require some ipaddress mangling to determine overlapping subnets.

This s expected wireguard behavior.

This does not currently affect crux (perhaps it did at some point). The crux script logic precludes this bug; confirmed in testing.

Works as expected in latest rolling: 1.3-rolling-20200724