it's not a bug, this command are able in ospf :
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 6 2023
after merge this ldp bug fixed , I saw that now it's already working . Could you check it ? I've tested on a lab and it seems to work :
I’m also seeing this error after the update to 1.3.4
That looks better:
chain VZONE_LOCAL_OUT { oifname "lo" counter packets 387 bytes 33672 return oifname "bond0.40" counter packets 14 bytes 496 jump NAME_LOCAL_TO_ALL oifname "bond0.40" counter packets 0 bytes 0 return oifname "bond0.70" counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL oifname "bond0.70" counter packets 0 bytes 0 return r packets 0 bytes 0 jump NAME_LOCAL_TO_ALL oifname { "bond0.7", "bond0.30", "bond0.90", "bond0.88" } counter packets 0 bytes 0 return oifname { "eth0", "pppoe0", "eth1.281" } counter packets 3 bytes 180 jump NAME_LOCAL_TO_ALL oifname { "eth0", "pppoe0", "eth1.281" } counter packets 0 bytes 0 return oifname "bond0.80" counter packets 2 bytes 80 jump NAME_LOCAL_TO_ALL oifname "bond0.80" counter packets 0 bytes 0 return oifname { "bond0.1", "podman-cntr-net" } counter packets 2 bytes 128 jump NAME_LOCAL_TO_ALL oifname { "bond0.1", "podman-cntr-net" } counter packets 0 bytes 0 return oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 return counter packets 0 bytes 0 drop comment "zone_LOCAL default-action drop" }
tested /resolved
Does anyone knows real scenario where permanently storing/saving this logs are required?
Yes, this feature is not working on 1.4, neither on 1.5
But I can't think on a real case where this logs are needed. I know that keeping information of NAT for certain ISP is mandatory due lo legal requirements. But writing a log entry for every conntrack status change seems like it will flood logs, and may consume more resources than expected.
With usage of netflow/slflow, maybe this required information can be obtained in the netflow collector, and do not increase load on vyos router.
It seems to be the difference between the vyos version build in the Dockerfile of librtr-dev and the Debian librtr-dev version (which works).
Thanks, I'll wait for the merge and test the new iso ASAP.
If you add the librtr-dev to the docker build image and build FRR (with the docker build image) yourself it works:
$ git clone -b current --single-branch https://github.com/vyos/vyos-build.git $ cd vyos-build $ vi docker/Dockerfile $ git diff diff --git a/docker/Dockerfile b/docker/Dockerfile index 953ea4c..baeb232 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -345,6 +345,9 @@ RUN apt-get update && apt-get install -y \ libnl-genl-3-dev \ libxtables-dev
Working on it! Thanks for the details!
Nov 5 2023
(20:39) cpo lnx01:~/vyos-1x [current] # git grep \"secret\" interface-definitions/ interface-definitions/vpn-ipsec.xml.in: <leafNode name="secret"> interface-definitions/vpn-l2tp.xml.in: <leafNode name="secret">
Yup, VPN site to site authentication credentials are stored as "secret" hence the patch.
Nov 4 2023
Do you have any example of in which context that exists?
In that PR, shouldnt also ifb* be included?
@n.fort Unfortunately, I'm hitting an issue with traffic sent from the router itself.
Running 1.4-rolling-202311021131.
Interfaces eth0 and pppoe0 are WAN. Interfaces bond0* are LAN.
For example, running dig google.nl @9.9.9.9 from the VyOS CLI will fail. The kernel log says:
PR added...
https://github.com/vyos/vyos-1x/pull/2435
PR https://github.com/vyos/vyos-1x/pull/2434
set service snmp community public client '127.0.0.1' set service snmp mib interface-max '25' set service snmp mib interface 'eth' set service snmp mib interface 'bond'
+1 for the other "virtual interfaces like lo, dummy, sstp. If such an interface is created - vyos.ifconfig library sets (or should set) all the appropriate sysctl stuff
Nov 3 2023
Shouldnt dummy* and some others be excluded aswell?
To fix it
sudo nano -c /lib/udev/rules.d/99-systemd.rules
Find sysctl line
# Apply sysctl variables to network devices (and only to those) as they appear. ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
Replace to:
# Apply sysctl variables to network devices (and only to those) as they appear. ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo|ppp*|ipoe*", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"
Tested with 1.5-rolling-202311030022 and working as expected.
PR for VyOS 1.4 https://github.com/vyos/vyos-1x/pull/2433
vyos@r4:~$ sudo udevadm monitor KERNEL[717.626843] remove /devices/virtual/net/ppp3466/queues/rx-0 (queues) KERNEL[717.626859] remove /devices/virtual/net/ppp3466/queues/tx-0 (queues) KERNEL[717.626903] remove /devices/virtual/net/ppp3466 (net) KERNEL[717.635679] remove /devices/virtual/net/ppp3468/queues/rx-0 (queues) KERNEL[717.635695] remove /devices/virtual/net/ppp3468/queues/tx-0 (queues) KERNEL[717.635769] remove /devices/virtual/net/ppp3468 (net) KERNEL[717.636144] remove /devices/virtual/net/ppp3469/queues/rx-0 (queues) KERNEL[717.636155] remove /devices/virtual/net/ppp3469/queues/tx-0 (queues) KERNEL[717.636181] remove /devices/virtual/net/ppp3469 (net) KERNEL[717.636536] remove /devices/virtual/net/ppp3458/queues/rx-0 (queues) KERNEL[717.636548] remove /devices/virtual/net/ppp3458/queues/tx-0 (queues) KERNEL[717.636614] remove /devices/virtual/net/ppp3458 (net) KERNEL[717.648940] remove /devices/virtual/net/ppp3470/queues/rx-0 (queues) KERNEL[717.648965] remove /devices/virtual/net/ppp3470/queues/tx-0 (queues) KERNEL[717.649018] remove /devices/virtual/net/ppp3470 (net) KERNEL[717.662658] remove /devices/virtual/net/ppp3473/queues/rx-0 (queues) KERNEL[717.662694] remove /devices/virtual/net/ppp3473/queues/tx-0 (queues) KERNEL[717.662705] remove /devices/virtual/net/ppp3473 (net) KERNEL[717.663198] remove /devices/virtual/net/ppp3471/queues/rx-0 (queues) KERNEL[717.663211] remove /devices/virtual/net/ppp3471/queues/tx-0 (queues) KERNEL[717.663255] remove /devices/virtual/net/ppp3471 (net) KERNEL[717.663423] remove /devices/virtual/net/ppp3472/queues/rx-0 (queues) KERNEL[717.663436] remove /devices/virtual/net/ppp3472/queues/tx-0 (queues) KERNEL[717.663465] remove /devices/virtual/net/ppp3472 (net) ^C
I think we may be talking about different things. The situation I am testing has the pair of QFX switches. An end server has a pair of interfaces in a bond with each interface going to one QFX. VyOS is configured with an interface to each QFX but not in a bond (just two different VLANs). The designated forwarder election for the segment to the end server is handled by the QFXs.
@shthead: Im talking about features in VyOS. I dont care what others such as Juniper does or doesnt do.
In T5698#163675, @Apachez wrote:@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:
https://www.arista.com/en/um-eos/eos-vxlan-configuration#topic_ckc_dh4_ynb
redundancy single-active
vs.
redundancy all-active
Nov 2 2023
The migration scripts still have an issue @n.fort I sent you the issues with loading a 1.4 rolling to 1.5 in slack
Good to know it worked @marc_s . Thanks for letting us know!
@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:
PR for VyOS 1.5 https://github.com/vyos/vyos-1x/pull/2431
@Viacheslav @n.fort Regarding https://github.com/vyos/vyos-1x/pull/2388: I just tested on 1.4-rolling-202311021131: ZBF config from 1.4-rolling-202304120317 loaded without a hitch.
This is a 8 zone, 959 line config.
I understand (and accept) the risks of running rolling.
In T5681#163634, @JeffWDH wrote:When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.
Snippet from vyos-migrate.log:
List of executed migration scripts: List of executed migration scripts: List of executed migration scripts: /opt/vyatta/etc/config-migrate/migrate/cluster/1-to-2 /opt/vyatta/etc/config-migrate/migrate/interfaces/31-to-32 /opt/vyatta/etc/config-migrate/migrate/nat/5-to-6 - op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface'] - op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name'] value: vtun0 replace: True - op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface'] - op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name'] value: vtun1 replace: True <omitted a bunch of NAT rules> /opt/vyatta/etc/config-migrate/migrate/nat/6-to-7 - op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name'] - op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'name'] value: vtun0 replace: True - op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name'] - op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'name'] value: vtun1 replace: True <omitted a bunch of NAT rules> /opt/vyatta/etc/config-migrate/migrate/nat66/1-to-2After readding them with the new syntax all is good, but it looks like for some reason the migration script didn't run on my system.
When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.
Part of those is fixed with telegraf update in T5701
Nov 1 2023
There is a bug when we use lowercase "cisco"
set service pppoe-server authentication radius rate-limit vendor 'cisco'
It doesn't work as vendor is Cisco not cisco
vyos@vyos-lns# sudo cat /usr/share/accel-ppp/radius/dictionary.cisco | grep -i vendor VENDOR Cisco
PR for 1.4 https://github.com/vyos/vyos-build/pull/451