- User Since
- Sep 10 2018, 3:30 PM (96 w, 1 d)
Closed in favor of https://phabricator.vyos.net/T1101
Wed, Jul 1
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.
Thu, Jun 25
Wed, Jun 24
Mon, Jun 15
@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
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):
Jan 13 15:29:51 vyos zebra: 0:10.230.230.0/30: Adding route rn 0x5612ea69d1f0, re 0x5612ea69d370 (type 2) Jan 13 15:29:51 vyos zebra: 0:10.230.230.0/30: Redist update re 0x5612ea69d370 (type 2), old (nil) (type -1) Jan 13 15:29:51 vyos zebra: 0:10.230.230.0/30: Adding route rn 0x5612ea69d490, re 0x5612ea69e110 (type 2) Jan 13 15:29:51 vyos zebra: 0:10.230.230.0/30: Redist update re 0x5612ea69e110 (type 2), old (nil) (type -1) Jan 13 15:29:51 vyos zebra: NHT processing check for zvrf default Jan 13 15:29:51 vyos zebra: 0:10.230.230.1/32: Evaluate RNH, type 0 Jan 13 15:29:51 vyos zebra: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30 Jan 13 15:29:51 vyos zebra: 0:10.230.230.1/32: Notifying client static about NH Jan 13 15:29:51 vyos zebra: 0:192.168.20.1/32: Evaluate RNH, type 0
Jan 13 15:33:23 vyos zebra: 0:10.230.230.0/30: Adding route rn 0x5574620a18b0, re 0x5574620a1930 (connected) Jan 13 15:33:23 vyos zebra: 0:10.230.230.0/30: Adding route rn 0x5574620a29b0, re 0x5574620a1850 (connected) Jan 13 15:33:23 vyos zebra: 0:10.230.230.0/30 update_from_ctx(): no fib nhg Jan 13 15:33:23 vyos zebra: 0:10.230.230.0/30 update_from_ctx(): rib nhg matched, changed 'true' Jan 13 15:33:23 vyos zebra: 0:10.230.230.0/30: Redist update re 0x5574620a1930 (connected), old 0x0 (None) Jan 13 15:33:23 vyos zebra: 0:10.230.230.1/32: Evaluate RNH, type Nexthop Jan 13 15:33:23 vyos zebra: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30 Jan 13 15:33:23 vyos zebra: 0:10.230.230.1/32: Notifying client static about NH Jan 13 15:33:23 vyos zebra: 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: 0:10.0.0.0/8: Adding route rn 0x5574620a1b10, re 0x5574620a1a30 (static) Jan 13 15:33:23 vyos zebra: netlink_route_multipath(): RTM_NEWROUTE 10.0.0.0/8 vrf 0(254) Jan 13 15:33:23 vyos zebra: netlink_route_multipath() (single-path): nexthop via 10.230.230.1 if 3(0) Jan 13 15:33:23 vyos zebra: netlink_talk: netlink-dp (NS 0) type RTM_NEWROUTE(24), len=60 seq=10 flags 0x501 Jan 13 15:33:23 vyos zebra: 0:10.0.0.0/8 update_from_ctx(): no fib nhg Jan 13 15:33:23 vyos zebra: 0:10.0.0.0/8 update_from_ctx(): rib nhg matched, changed 'true' Jan 13 15:33:23 vyos zebra: 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.
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
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. :(
Dec 18 2019
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.
Nov 25 2019
Nov 12 2019
Nov 2 2019
Oct 25 2019
Oct 21 2019
Oct 8 2019
BGP scan-time parameter is unneeded in current FRRouting and VyOS - there are used modern next-hop tracking instead. You must avoid using this option. I have prepared PR to delete this option and migrate the old configuration, where it exists:
Sep 24 2019
Sep 16 2019
Sep 11 2019
Sep 4 2019
IP6GRE tunnels are supported in 1.2-rolling-201909041703. You are welcome to test.
Aug 27 2019
Pull request for fixing this problem: https://github.com/vyos/vyatta-netflow/pull/4
Aug 26 2019
Aug 21 2019
The problem is in FRRouting itself. It can be reproduced in 7.0.1-20190820-04-g047efd6, 7.1-20190820-02-g1ed807a. But in 7.2-dev-20190820-03-g9316c82 everything work as expected.
We should try to find which changes fixed this problem and reapply it to one of the current stable FRR versions or wait for the next stable.
Aug 9 2019
I have added two PRs with some fixes and new features. The most valuable changes:
- Fixed the bug, which prevents to change or delete BFD peers with custom options. For example, when any of source address/interface, multihop was used, such peers could not be deleted or changed.
- Added configuration checks, which should prevent adding BFD option to BGP neighbors or peer-groups without corresponding peers configuration in protocols bfd. If BGP and BFD configurations are out of sync, BGP sessions could be very unstable.
- Added configuration check, which should prevent to delete peers from protocols bfd if they are still used in BGP.
- Some other small fixes and changes.
Also, was added several new options:
set protocols bfd peer IP echo-mode set protocols bfd peer IP interval echo-interval
set protocols bgp ASN neighbor IP bfd check-control-plane-failure