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'
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Jul 16 2022
Jul 16 2022
diekos added a comment to T4028: FRR 8.1 routes not being applied to routing table after reboot if an interface has 2 ip addresses.
@Viacheslav
Yes, the output of show ip route and sudo ip route are after a reboot.
Jul 15 2022
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.
Viacheslav edited projects for T2763: New SNMP resource request - SNMP over TCP, added: VyOS 1.3 Equuleus (1.3.2); removed VyOS 1.3 Equuleus (1.3.0).
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.
Viacheslav added a comment to T4028: FRR 8.1 routes not being applied to routing table after reboot if an interface has 2 ip addresses.
@diekos Is it working after reboot?
c-po closed T4536: FRR: move to systemd for daemon control, a subtask of T4535: FRR: upgrade to stable/8.3 version, as Resolved.
Jul 14 2022
Jul 14 2022
diekos added a comment to T4028: FRR 8.1 routes not being applied to routing table after reboot if an interface has 2 ip addresses.
Just tested this on VyOS 1.4-rolling-202207111030, with the following commands:
Viacheslav renamed T4533: Radius clients don’t have simple permissions from Radius clients doesnt have simple permissions to Radius clients don’t have simple permissions.
c-po changed the status of T4534: bond: bridge: error out if member interface is assigned to a VRF instance, a subtask of T4525: Delete interface from VRF and add it to bonding error, from Open to In progress.
c-po changed the status of T4534: bond: bridge: error out if member interface is assigned to a VRF instance from Open to In progress.
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#
Viacheslav added a project to T4533: Radius clients don’t have simple permissions: VyOS 1.4 Sagitta.
I propose a patch to fix this issue:
Demo QPPB implementation supporting bgp-policy destination mode:
0001-QPPB-DEMO-FRR.patch24 KBDownload
Similar problem in the latest rolling releases (vyos-1.4-rolling-202207111030). Traffic policy (limiter) not set in live configuration.
jestabro changed the status of T4491: Use empty string for internal name of root node of config_tree, a subtask of T4235: Add config tree diff algorithm, from Unknown Status to Resolved.
jestabro changed the status of T4491: Use empty string for internal name of root node of config_tree from Unknown Status to Resolved.
Jul 13 2022
Jul 13 2022
Jul 12 2022
Jul 12 2022
Viacheslav moved T4084: Dehardcode the default login banner from Need Triage to Finished on the VyOS 1.3 Equuleus (1.3.0) board.
Viacheslav changed the status of T4113: Incorrect GRUB configuration parsing from In progress to Needs testing.
c-po changed the status of T4525: Delete interface from VRF and add it to bonding error from Open to In progress.
I only see one solution - exclude mirror node from interface and add it as a separate option/service
set service redirect|port-mirror <x> source tunX set service redirect|port-mirror <x> destination tunY
As tc filter applied for every interface step by step and in this case (adding tun0) we don't have tun1 yet
To reproduce:
Viacheslav moved T4527: Prevent to create VRF name default from Open to Finished on the VyOS 1.4 Sagitta board.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1410
Viacheslav changed the status of T4527: Prevent to create VRF name default from Open to In progress.
Unknown Object (User) added a comment to T3655: NAT doesn't work correctly with VRF.
Hi, but one more thing related NAT and VRF in 1.4 rolling. As you know it uses NF MAP, to isolate conntrack tables, so we need to create some design to fix this moment. Matbe with adding some mark
c-po changed the status of T3507: Bond with mode LACP show u/u in show interfaces even if peer is not configured from Open to Needs testing.
c-po added a comment to T3507: Bond with mode LACP show u/u in show interfaces even if peer is not configured.
set interfaces bonding bond0 member interface 'eth1' set interfaces bonding bond0 member interface 'eth2' set interfaces bonding bond0 vif 10
Jul 11 2022
Jul 11 2022
I've re-tested this issues with the initial configuration, nat source / mesquered/ destination , it seems to work as @Dmitry said. The conntrack doesn't show the connection as [UNREPLIED] , it's established :
Prototype PR using Tayga: https://github.com/vyos/vyos-1x/pull/1408
Unknown Object (User) renamed T4527: Prevent to create VRF name default from Preevent to create VRF name default to Prevent to create VRF name default.
Unknown Object (User) created T4527: Prevent to create VRF name default.
Viacheslav added a comment to T1311: WAN load-balancing can't flush connections when conntrack-sync is enabled.
Jul 11 2022, 3:11 PM · VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-epa1), Restricted Project, test
Viacheslav added a project to T1311: WAN load-balancing can't flush connections when conntrack-sync is enabled: VyOS 1.4 Sagitta.
Jul 11 2022, 2:58 PM · VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-epa1), Restricted Project, test
Viacheslav changed Version from VyOS 1.4-rolling-202207111030 to VyOS 1.4-rolling-202207111030, VyOS 1.3-stable-202207110427 on T4525: Delete interface from VRF and add it to bonding error.
Similar task T3810 points 5, 8
Viacheslav added a comment to T4523: OP-mode Extend conntrack output to get marks, zones and directions.
PR https://github.com/vyos/vyos-1x/pull/1407
vyos@r14# run show conntrack table ipv4 Id Original src Original dst Reply src Reply dst Protocol State Timeout Mark Zone ---------- ------------------- ----------------- ----------------- ------------------- ---------- ----------- --------- ------ ------ 3529842617 192.168.122.1:53508 192.168.122.14:22 192.168.122.14:22 192.168.122.1:53508 tcp ESTABLISHED 431999 0 4102830655 192.0.2.10 1.0.0.1 1.0.0.1 192.168.122.14 icmp 18 0 59651 179791316 192.0.2.10 1.1.1.1 1.1.1.1 192.168.122.14 icmp 12 0 59651 [edit] vyos@r14#
Viacheslav renamed T4523: OP-mode Extend conntrack output to get marks, zones and directions from OP-mode Extend conntrack output to get marks and zones to OP-mode Extend conntrack output to get marks, zones and directions.
Viacheslav removed a project from T3655: NAT doesn't work correctly with VRF: VyOS 1.3 Equuleus (1.3.0).
Unknown Object (User) added a comment to T3655: NAT doesn't work correctly with VRF.
Today I tested VRF route leaking and NAT. It works on 1.3.1-S1. Simple configuration:
c-po renamed T3318: Update Linux Kernel to v5.4.208 / 5.10.142 from Update Linux Kernel to v5.4.197 / 5.10.123 to Update Linux Kernel to v5.4.204 / 5.10.129.
c-po moved T4522: bond: add ability to specify mii monitor interval via CLI from Open to Finished on the VyOS 1.4 Sagitta board.
Jul 10 2022
Jul 10 2022
c-po updated the task description for T4522: bond: add ability to specify mii monitor interval via CLI.
c-po updated the task description for T4522: bond: add ability to specify mii monitor interval via CLI.
c-po changed the status of T4522: bond: add ability to specify mii monitor interval via CLI from Open to In progress.
c-po moved T4515: Reduce telegraf binary size from Need Triage to In Progress on the VyOS 1.3 Equuleus (1.3.2) board.
c-po moved T4521: bond: ARP monitor interval is not configured despite set via CLI from Need Triage to In Progress on the VyOS 1.3 Equuleus (1.3.2) board.
c-po moved T4521: bond: ARP monitor interval is not configured despite set via CLI from Open to Finished on the VyOS 1.4 Sagitta board.
c-po changed the status of T4521: bond: ARP monitor interval is not configured despite set via CLI from Open to In progress.
The same task T4511
Viacheslav changed the status of T3409: Add back TCP-MSS Clamp to PMTU from Confirmed to Needs testing.
@raphielscape Could you re-test it?
vyos@r14# set interfaces ethernet eth0 ip adjust-mss Possible completions: clamp-mss-to-pmtu Automatically sets the MSS to the proper value <500-65535> TCP Maximum segment size in bytes
Viacheslav closed T3836: Setting a default IPv6 route while getting IPv4 gateway via DHCP removes the IPv4 gateway as Resolved.
Fixed
S>* 0.0.0.0/0 [210/0] via 192.0.2.1, eth1, weight 1, 00:02:31 C>* 192.0.2.0/24 is directly connected, eth1, 00:02:31 C>* 192.168.122.0/24 is directly connected, eth0, 00:04:09
Jul 9 2022
Jul 9 2022
Viacheslav removed a project from T4499: NAT source translation not showing a single output: VyOS 1.3 Equuleus (1.3.2).
Viacheslav moved T4499: NAT source translation not showing a single output from Open to Finished on the VyOS 1.4 Sagitta board.
Viacheslav added a project to T4499: NAT source translation not showing a single output: VyOS 1.3 Equuleus (1.3.2).
Unknown Object (User) added a comment to T3353: PPPoE server wrong vlan-range generating config.
@Viacheslav, thanks.
Already fixed in roling
vyos@vyos# set service pppoe-server interface eth0 vlan-range Possible completions: start-end VLAN monitor range for the automatic creation of vlans (e.g. 1-4094)
Viacheslav changed the status of T4508: Problem with values of the same environment in different event handlers from In progress to Needs testing.
Viacheslav changed the status of T4499: NAT source translation not showing a single output from Open to In progress.
Any chance you can test this on 1.4 rolling image?