It is possible to use https://github.com/vyos/vyos-1x/blob/b704d0676ab2d623d2eeb1ed4dc1bcf2a2c4a5e2/python/vyos/logger.py for this purpose now.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 31 2020
Jul 29 2020
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.
Jul 24 2020
Jul 23 2020
Jul 14 2020
Jul 13 2020
Closed in favor of https://phabricator.vyos.net/T1101
Jul 1 2020
This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.
Jun 25 2020
Jun 24 2020
Jun 15 2020
@s.lorente can you check this with actually configured tc values?
Jun 11 2020
The set protocols bgp XXX neighbor XXX address-family ipv6-unicast peer-group XXX command generate the router bgp XXX; address-family ipv6; neighbor XXX peer-group XXX', for vtysh, which does not supported (anymore? I cannot find any commits in FRR about syntax change, maybe this was migrated from old quagga).
Jun 10 2020
Jun 8 2020
@c-po I have not tried this previously, but if it works well, I would like to keep it for kernel debugging on bare-metal devices.
May 13 2020
May 12 2020
May 9 2020
The bug is produced because of deleted deprecated option in vtysh. Before FRR 7.3:
root@vyos:/home/vyos# vtysh -c "show ip community-list 10" This config option is deprecated, and is scheduled for removal. if you are using this please migrate to the below command. 'show bgp community-list <(1-500)|WORD> detail' % Can't find community-list
Starting from 7.3:
root@vyos:/home/vyos# vtysh -c "show ip community-list 10" % Unknown command: show ip community-list 10
May 4 2020
Need to check again with 1.3, as may be solved by: https://phabricator.vyos.net/T1291
Apr 30 2020
Apr 28 2020
Apr 27 2020
Apr 20 2020
Apr 17 2020
Apr 13 2020
Apr 10 2020
Apr 8 2020
Hello, @adestis!
Support of transition-scripts was added to sync-groups in a rolling version.
I have investigated this a bit. Most operations for ports are doing one-by-one. Deleting as I see is always done in this way. Adding a range is done by a single command, but checking ports are doing one-by-one.
If we skip/change mentioned checking for adding ports, this should decrease initial commit time. But when we try to change/delete ports, the issue will back.
I think that there should be better to reimplement the whole firewall group section in Python, instead of fixing this logic now.
Already possible via Cloud-init. For different environments may be required differently tuned images (data sources, additional tools like guest agents, etc.).
Apr 6 2020
Apr 3 2020
Closed due to inactivity.
Apr 2 2020
In the current 1.3 branch the original issue was resolved and added STOP script support. It is necessary to test this and review the possibility to backport the solution into 1.2.
Apr 1 2020
Mar 27 2020
Mar 24 2020
Mar 12 2020
Mar 11 2020
Mar 10 2020
Mar 2 2020
Feb 18 2020
Jan 30 2020
Jan 29 2020
Jan 24 2020
Jan 13 2020
The described problem exists in stable FRR 7.2, but fixed in FRR master branch by https://github.com/FRRouting/frr/pull/5184
We have tested 7.2 with this PR applied, and the bug was gone, so we can apply this PR to our FRR package and solve the problem.
In FRR 7.0.1 (VyOS 1.2.3) was some bug, due to which static routes were not updated (maybe, not in all cases or environments) after the next-hop state change. In VyOS 1.2.4 we use stable FRR 7.2, which processes this situation without problems. An example (key point from FRR debug log):
FRR 7.0.1:
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Adding route rn 0x5612ea69d1f0, re 0x5612ea69d370 (type 2) Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Redist update re 0x5612ea69d370 (type 2), old (nil) (type -1) Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Adding route rn 0x5612ea69d490, re 0x5612ea69e110 (type 2) Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Redist update re 0x5612ea69e110 (type 2), old (nil) (type -1) Jan 13 15:29:51 vyos zebra[1041]: NHT processing check for zvrf default Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: Evaluate RNH, type 0 Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30 Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: Notifying client static about NH Jan 13 15:29:51 vyos zebra[1041]: 0:192.168.20.1/32: Evaluate RNH, type 0
FRR 7.2:
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Adding route rn 0x5574620a18b0, re 0x5574620a1930 (connected) Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Adding route rn 0x5574620a29b0, re 0x5574620a1850 (connected) Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30 update_from_ctx(): no fib nhg Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30 update_from_ctx(): rib nhg matched, changed 'true' Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Redist update re 0x5574620a1930 (connected), old 0x0 (None) Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: Evaluate RNH, type Nexthop Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30 Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: Notifying client static about NH Jan 13 15:33:23 vyos zebra[1042]: rib_add_multipath: 0:10.0.0.0/8: Inserting route rn 0x5574620a1b10, re 0x5574620a1a30 (static) existing (nil) Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8: Adding route rn 0x5574620a1b10, re 0x5574620a1a30 (static) Jan 13 15:33:23 vyos zebra[1042]: netlink_route_multipath(): RTM_NEWROUTE 10.0.0.0/8 vrf 0(254) Jan 13 15:33:23 vyos zebra[1042]: netlink_route_multipath() (single-path): nexthop via 10.230.230.1 if 3(0) Jan 13 15:33:23 vyos zebra[1042]: netlink_talk: netlink-dp (NS 0) type RTM_NEWROUTE(24), len=60 seq=10 flags 0x501 Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8 update_from_ctx(): no fib nhg Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8 update_from_ctx(): rib nhg matched, changed 'true' Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8: Redist update re 0x5574620a1a30 (static), old 0x0 (None)
So, configured static routes updating properly.
Jan 2 2020
Dec 31 2019
The problem is fixed in 1.3.
Hello, @MapleWang!
Unfortunately, I cannot find any other reliable way to configure vyos-hostsd service to be running before the vyos-router. In fact, vyos-hostsd is really necessary to be running for proper work of the VyOS system, so we can consider this even from the other point of view - how to keep all services operable after the vyos-router restart?
If you will have any ideas, which can help to decrease the overall impact of this situation, we would be happy to get them.
Dec 19 2019
Hello, @MapleWang!
Thank you for pointing our attention to this issue! It is really bad that such simple action as changing hostname in some cases (well, in fact not only this but it is easy to reproduce) leads to the whole router crash.
The problem consists of several parts:
- In old systemd versions (which is used in Debian Jessie and VyOS 1.2) exists a problem, when during a restart of systemd-journald all pipes between this daemon and systemd services are disconnecting.
- In vyos-hostsd, which is responsible for hostname and DNS and controlled by systemd we used print() for logging and debug purposed without enough handling of errors.
So, when arises the situation when there is no PIPE connection between vyos-hostsd and systemd-journald, vyos-hostsd not able to print messages and crashes. :(
@c-po, there is also third PR in vyos-buid: https://github.com/vyos/vyos-build/pull/69
Dec 18 2019
Thanks, @elbuit !
We have prepared PR with full functionality: https://github.com/vyos/vyos-1x/pull/187
It would be great if you will join us and help to test it, find all bugs and fix them. :)
Hello, @elbuit!
As I see, NAT events can be recorded only by nfacctd, and therefore this is not possible with the current way to capture traffic (by NFLOG + uacctd). Fix me, if I was missed something, please.
Dec 17 2019
Hello, @elbuit !
We almost ready to release rewritten flow-accounting, and maybe we will be able to include your request into it. Can you describe more detailed what exactly records you want to have? It would be good to see an example pmacct configuration for your case.
Dec 13 2019
Dec 9 2019
Thanks, @trae32566 for the information! I would be happy to change this fix in that way, which does not allow to place unwanted records to resolv.conf at all, but I cannot catch the same situation like yours to collect enough diagnostics data to be sure in the reason of such behavior.
Dec 6 2019
I have tried multiple times to reproduce this with 1.2-rolling-201912060217 with no luck. It would be great if together with logs you will provide a detailed description of the environment. Because, possible that even CPU cores count or memory size can lead to some condition, in which dhclient-script cannot get proper values from config and add unwanted servers to the resolv.conf.
Dec 5 2019
Could you provide the log output in a case when DNS servers, received from DHCP appears in resolv.conf? As I understand, it should happen immediately after the boot.
Also, please, check if they are not deleting after the first DHCP lease renewal.