Not actual for 1.5/1.4
@mrlocke Can you re-check the 1.3?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 24 2024
Apr 23 2024
@doctorpangloss Any updates?
@modzilla99 Could you provide an example of set commands to reproduce?
Tested as working in: VyOS 1.5-rolling-202404230019
In T6258#184716, @Viacheslav wrote:Most likely needs to change priority to 319 for the sysctl
vyos@r4:~$ /usr/libexec/vyos/priority.py | match "ethernet|sysctl" 300 interfaces_virtual-ethernet.py ['interfaces', 'virtual-ethernet'] 318 interfaces_ethernet.py ['interfaces', 'ethernet'] 318 system_sysctl.py ['system', 'sysctl'] 321 interfaces_pseudo-ethernet.py ['interfaces', 'pseudo-ethernet'] vyos@r4:~$
What happens if another interface/value occupies the index 101?
For example, PPPoE-server and PPP interface can generate thousands of interfaces
It was filtered in https://vyos.dev/T2086 to avoid pam_unix mess
Can't reproduce it, close the task
Most likely needs to change priority to 319 for the sysctl
vyos@r4:~$ /usr/libexec/vyos/priority.py | match "ethernet|sysctl" 300 interfaces_virtual-ethernet.py ['interfaces', 'virtual-ethernet'] 318 interfaces_ethernet.py ['interfaces', 'ethernet'] 318 system_sysctl.py ['system', 'sysctl'] 321 interfaces_pseudo-ethernet.py ['interfaces', 'pseudo-ethernet'] vyos@r4:~$
I have asked the OP @canoziia to provide such in the forum.
Extend to <1-65535>
PR https://github.com/vyos/vyos-1x/pull/3353
What do I need to do to get these values?
root@r1-right:/home/vyos# sysctl net.ipv6.neigh.eth3/2.base_reachable_time_ms sysctl: cannot stat /proc/sys/net/ipv6/neigh/eth3.2/base_reachable_time_ms: No such file or directory
I can only refer to whats unfolded on the forum at https://forum.vyos.io/t/how-to-set-net-ipv6-neigh-etha-b-base-reachable-time-in-vyos/14304
Apr 22 2024
@Viacheslav or another of the Maintainers:
Could you provide the full set of commands to reproduce?
So the root cause here is that vrf.py runs prior to vrf_vni.py where the first one eliminates all vni configuration within FRR.
The main reason for this weird logic is T5492.
Any news about this issue @SrividyaA and @c-po ?