@Merijn Have such problems been repeated?

The problem is that vti interfaces are only created when VPN is configured this is done very late with priority 900. VXLAN, bridge etc (also in 1.2) use a lower priority. The only solution will be that the vti interface is added imediately and then later bound to the VPN.

The issue did not reproduce neither in 1.2.5 nor in 1.3 version.
Try in the new release and re-open the ticket if any new information appeared.

@olofl I can't confirm this bug int the 1.2.5 LTS version.

I can't confirm this bug.

vyos@vyos# set vpn ipsec ike-group IKEv2_DEFAULT mobike disable 
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# run show version 
Version:          VyOS 1.2.5
Built by:         Sentrium S.L.
Built on:         Sun 12 Apr 2020 15:18 UTC
Build UUID:       1695c660-d785-4b16-a54b-66d6a02ea24f
Build Commit ID:  48cc9fc46569e6

That configuration does not work in 1.2.5 either - we probably should exclude vti from VXLAN source interface?

In latest rolling releases this will break b/c of:

@c-po In my vyos, the following commands run successfully, and the rule settings are normal, but the rules are not tested to be effective and correct. For reference only, if I have time, I will open the eve ng simulation environment.

@c-po Since I can't find a suitable place to use ndptool send, in this task list, cancel the implementation of this function. If necessary, the user can run it directly from the command, and now submit the correction. If possible, please re audit pr

What is here:

Although this document may not be a direct help, it may help us understand how to set up IPv6 NAT for nftables?

T1194

It may be a good idea to also have an option to hook debug logging to syslog.

It is possible to use https://github.com/vyos/vyos-1x/blob/b704d0676ab2d623d2eeb1ed4dc1bcf2a2c4a5e2/python/vyos/logger.py for this purpose now.

Yes, it would solve the issue ... but ... currently, we re-apply the whole interface setting, so there is no change to have the vyos and live configuration not sync'ed.
This would be lost. It is a trade-off, but it could be done. It would be however the only sub-system working that way.

Changing description in a master transition script will lead to an endless loop, because of:

1. Description change (or any other interface update) in a script trigger EthernetIf.update().
2. EthernetIf.update() trigger a lot of interface changes:

Jul 29 14:05:36 vyos sudo[3097]:     root : TTY=ttyS0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/bin/sh -c VYOS_TAGNODE_VALUE='eth1' /usr/libexec/vyos/conf_mode/interfaces-ethernet.py
Jul 29 14:05:36 vyos sudo[3097]: pam_unix(sudo:session): session opened for user root by vyos(uid=0)
Jul 29 14:05:36 vyos control.py[3098]: set_interface: alias,
Jul 29 14:05:36 vyos control.py[3098]: set_interface: link_detect, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: vrf,
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_cache_tmo, 30
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_filter, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_accept, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_announce, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_ignore, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp_pvlan, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_forwarding, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_accept_ra, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_autoconf, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_dad_transmits, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: mtu, 1500
Jul 29 14:05:36 vyos control.py[3098]: set_interface: alias, MASTER_by_script
Jul 29 14:05:36 vyos control.py[3098]: set_interface: link_detect, 1
Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) Entering BACKUP STATE
Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) sent 0 priority
Jul 29 14:05:36 vyos control.py[3098]: set_interface: vrf,
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_cache_tmo, 30
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_filter, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_accept, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_announce, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_ignore, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp_pvlan, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_forwarding, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_accept_ra, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_autoconf, 0
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_dad_transmits, 1
Jul 29 14:05:36 vyos control.py[3098]: set_interface: gro, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: gso, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: sg, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: tso, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: ufo, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: admin_state, up
Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) Entering MASTER STATE
Jul 29 14:05:36 vyos control.py[3098]: set_interface: gro, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: gso, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: sg, off
Jul 29 14:05:36 vyos control.py[3098]: set_interface: tso, off
Jul 29 14:05:37 vyos control.py[3098]: set_interface: ufo, off
Jul 29 14:05:37 vyos control.py[3098]: set_interface: admin_state, up

3. Something from this all trigger keepalived interface reinitialization.
4. Keepalived change VRRP state to BACKUP and then MASTER, and run transition scripts.
5. GOTO 1.

Ideally which interface is master/slave should be recorded and handled by VyOS so that users do not have to put some workaround like this one to know.

Removing this line from the master prevents erroneous changes master/backup. And CPU displays normal values.

I do not have a lab to reproduce this ATM.

@c-po I have changed the top-level command, maybe it's better, can you help me see it, if possible, request a merge, otherwise, please reply?

@c-po I have changed the top-level command, maybe it's better, can you help me see it, if possible, request a merge, otherwise, please reply?

PR https://github.com/vyos/vyatta-cfg-firewall/pull/18

I should add that this problem has existed for at least a couple months, right up until 1.3-rolling-202007241919. Rolling builds after that one appear to ignore the prefix-delegation configuration entirely (T2740), so they don't exhibit this problem.

This is because our other daemons are written using zeromq and the fact that pynng is not a part of the upstream debian source.

It seems that the problem is serious and under attention

The master change state every few seconds.

Jul 29 07:52:39 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-master.sh
Jul 29 07:52:40 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE
Jul 29 07:52:40 vyos Keepalived_vrrp[1821]: (lan) sent 0 priority
Jul 29 07:52:40 vyos Keepalived_vrrp[1821]: (lan) Entering MASTER STATE
Jul 29 07:52:41 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-fail.sh
Jul 29 07:52:42 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE
Jul 29 07:52:42 vyos Keepalived_vrrp[1821]: (lan) sent 0 priority
Jul 29 07:52:42 vyos Keepalived_vrrp[1821]: (lan) Entering MASTER STATE
Jul 29 07:52:43 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-master.sh
Jul 29 07:52:44 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE
Jul 29 07:52:44 vyos Keepalived_vrrp[1821]: (lan) sent 0 priority
Jul 29 07:52:44 vyos Keepalived_vrrp[1821]: (lan) Entering MASTER STATE
Jul 29 07:52:45 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-fail.sh
Jul 29 07:52:46 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE
Jul 29 07:52:46 vyos Keepalived_vrrp[1821]: (lan) sent 0 priority
Jul 29 07:52:46 vyos Keepalived_vrrp[1821]: (lan) Entering MASTER STATE
Jul 29 07:52:46 vyos Keepalived_vrrp[1821]: Warning: Failed to connect to the agentx master agent ([NIL]):
Jul 29 07:52:47 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-master.sh
Jul 29 07:52:48 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE
Jul 29 07:52:48 vyos Keepalived_vrrp[1821]: (lan) sent 0 priority
Jul 29 07:52:48 vyos Keepalived_vrrp[1821]: (lan) Entering MASTER STATE
Jul 29 07:52:49 vyos keepalived-fifo.py[1822]: Running the command: /config/scripts/vrrp-trans-fail.sh
Jul 29 07:52:50 vyos Keepalived_vrrp[1821]: (lan) Entering BACKUP STATE

Please consider using zeromq instead of pynng

Here is a draft of what I meant when I said reworking the XML schema.

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