- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 29 2020
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:
- Description change (or any other interface update) in a script trigger EthernetIf.update().
- 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
- Something from this all trigger keepalived interface reinitialization.
- Keepalived change VRRP state to BACKUP and then MASTER, and run transition scripts.
- 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?
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.
Jul 28 2020
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?
This feature request will be closed because the community does not agree to the replacement
Jul 27 2020
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
@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.
set policy route PBR rule 10 destination address '10.0.0.1' set policy route PBR rule 10 set table '10' set policy route PBR rule 10 source address '100.64.0.1' set policy route PBR rule 20 destination address '10.0.0.2' set policy route PBR rule 20 set table '20' set policy route PBR rule 20 source address '100.64.0.1'
Fixed, VyOS 1.3-rolling-202007270117
I'll mark it as resolved.
Reopen it if necessary.
vyos@r1-roll:~$ show protocols static arp Address HWtype HWaddress Flags Mask Iface 192.168.122.1 ether 52:54:00:f5:e8:14 C eth0 192.168.100.1 ether 52:54:00:d8:74:1f C eth1 192.168.122.12 ether 52:54:00:48:bb:cd C eth
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.
Jul 26 2020
This fix remains an open discussion with @zsdc and @Dmitry
Thanks - added a note to the docs.
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.