This is a behavior "by design". The prefix-len option cannot be used for BGP routes. We should add this notice to the CLI.
Check: http://docs.frrouting.org/en/latest/routemap.html#clicmd-match-ip-address-prefix-len-0-32
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 19 2022
While i like the inclusion of NAT64 inside vyos (And the effort vfreex has made), i believe that tayga is not the way to go, it was last updated on 2010-12-12 according to the readme in it. Jool on the other hand has a bigger throughput being kernel module. The only issue i believe is the module compilation cause configuration is quite easy.
Can you check with the latest rolling release? it uses FRR 8.3
Probably a problem with FRR
Will be fixed in the next rolling release. Thanks!
@dannyvanderaa this is true - but as of VyOS 1.3 there is no longer an operator mode due to security issues. Operator level was removed, it will come back once the entire codebase rewrite is complete.
Several access levels are required on our end. In my opinion an operator / read only user should also be able to perform some basic commands (like ping and arp)
Jul 18 2022
Also cipher changes require a reboot. Nice bug - thanks for this riddle ;)
This change currently removes the nstat plugin which is used in the configuration (https://github.com/vyos/vyos-1x/blob/current/data/templates/monitoring/telegraf.j2#L108).
This results in telegraf crashing on startup. Adding the plugin back to the https://github.com/vyos/vyos-build/blob/current/packages/telegraf/plugins/inputs/all/all.go file fixes this (Tested by compiling a patched package and installing it on a broken install).
As far as I can tell this is the only missing plugin.
Also, there are no any Inbound/Outbound packets with aes-256
vyos@r14:~$ sudo ip -s macsec show 7: macsec1: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off cipher suite: GCM-AES-256, using ICV length 16 TXSC: eeb5e212f04f0001 on SA 0 stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun 0 0 0 0 0 0 0 0 stats: OutPktsProtected OutPktsEncrypted OutOctetsProtected OutOctetsEncrypted 0 0 0 0 offload: off vyos@r14:~$
But service starts without issues:
vyos@r14:~$ sudo systemctl status [email protected] ● [email protected] - WPA supplicant daemon (macsec-specific version) Loaded: loaded (/lib/systemd/system/[email protected]; disabled; vendor preset: enabled) Active: active (running) since Mon 2022-07-18 20:07:16 EEST; 18min ago Main PID: 1802 (wpa_supplicant) Tasks: 1 (limit: 9411) Memory: 4.4M CPU: 101ms CGroup: /system.slice/system-wpa_supplicant\x2dmacsec.slice/[email protected] └─1802 /sbin/wpa_supplicant -c/run/wpa_supplicant/vxlan1.conf -Dmacsec_linux -ivxlan1
set protocols bgp local-as 200 set protocols bgp peer-group foo remote-as external set protocols bgp peer-group foo address-family ipv4-unicast ipv6-unicast set protocols bgp neighbor 1.1.1.1 peer-group foo commit
This might confuse the users as now there is sensitive information again, but a different one.
Confirmed to work correctly on version VyOS 1.4-rolling-202207180802.
As I know we have not access by level for now, maybe we should keep shell:priv-lvl=15 by default?
Duplicate T3871
In T4533#126578, @Viacheslav wrote:It is operator level, that shouldn’t have permission for configurations. Only basic diagnostics (op-mode)
This seems to be more inconsistent than it has been before.
It works fine with my environment. With the new image too:
VyOS 1.4-rolling-202207160217
It is operator level, that shouldn’t have permission for configurations. Only basic diagnostics (op-mode)
can you please share your configuration? Using Microsoft NPS as RADIUS backend with this configuration I can not reproduce the issue.
Jul 17 2022
Jul 16 2022
Although this task is closed, I'd like to mention that after this change we are now defining rulesets with "policy route6" and binding them to interfaces with "interfaces ... policy ipv6-route". This seems to be more inconsistent than it has been before. Besides, although such changes are handled in a migration script for static configurations, they break automation scripts and require version specific fixes.
In T3435#115394, @n.fort wrote:Error still present on VyOS 1.4-rolling-202201020317
vyos@vyos:~$ show nat source rules Traceback (most recent call last): File "/usr/libexec/vyos/op_mode/show_nat_rules.py", line 114, in <module> print(format_nat_rule.format(rule, srcdests[0], tran_addr, interface)) IndexError: list index out of range Rule Source Translation Outbound Interface ---- ------ ----------- ------------------ vyos@vyos:~$ show ver Version: VyOS 1.4-rolling-202201020317 Release train: sagittaNat config in this example:
vyos@vyos:~$ show config comm | grep nat set nat source rule 10 description 'Masquerade to NAT' set nat source rule 10 outbound-interface 'eth0' set nat source rule 10 translation address 'masquerade'
@Viacheslav
Yes, the output of show ip route and sudo ip route are after a reboot.
Jul 15 2022
@a.apostoliuk Could you specify how to reproduce this bug?
Some CLI config examples and/or some pings that indicate the issue.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1416
I tested 1.4-rolling-202207111030 and this seems to be resolved, including showing peers in the help.
Fix smoketest for 1.3 https://github.com/vyos/vyos-1x/pull/1415
PR for 1.4 https://github.com/vyos/vyos-1x/pull/1414
Requires update smoketests
@diekos Is it working after reboot?
Jul 14 2022
Just tested this on VyOS 1.4-rolling-202207111030, with the following commands:
It is different shells in 1.4 and 1.3 for this user config
In 1.3 it seems correct:
vyosuser@r1# echo $SHELL /sbin/radius_shell [edit] vyosuser@r1#
I propose a patch to fix this issue:
Demo QPPB implementation supporting bgp-policy destination mode:
Similar problem in the latest rolling releases (vyos-1.4-rolling-202207111030). Traffic policy (limiter) not set in live configuration.