again. It says - download complete. And i can get it from the message:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 7 2023
In T5045#144137, @aserkin wrote:
Thank you for the hint, @c-po
Attached the entire config we have on the node.
There're not much BGP peers, but quite a number of VRFs which terminate remote access l2tp subscribers.
I'd really appreciate any advice on the system optimization for that particular task - ideally i'd like this node to terminate up to 20k l2tp subscribers with very low traffic (not exceeding 0.5gbps i guess).
Well there should be no harm in lifting the limit of open file descriptors for FRR as its a huge process tree.
Can you share your entire protocols configuration tree so we see what else is configured?
Mar 6 2023
The bfdd process did not start until i changed LimitNOFILE=1024 to LimitNOFILE=2048 in /lib/systemd/system/frr.service
That did the trick, but i'm not sure it's a good solution.
What do you think, @Viacheslav ?
The limits look like standard
root@nn-vlns-3-1:~# ulimit -Hn
1048576
root@nn-vlns-3-1:~# ulimit -Sn
1024
root@nn-vlns-3-1:~# sysctl fs.file-max
fs.file-max = 9223372036854775807
@n.fort I apologize for the late entry here - could this also be exposed for NAT rules?
Edit: wow you guys worked so fast on this it got pulled before I could add this request :D
PR https://github.com/vyos/vyos-1x/pull/1870
>>> from vyos.template import range_to_regex >>> >>> range_to_regex(['11-12', '14-15']) '(1[1-2]|1[4-5])' >>> >>>
I created a separate task for it T5057
The second bug is interface Regex does not work
Get:
interface=re:eth1\.\d+
Expect:
interface=re:^eth1\.(200\d|20[1-9]\d|2[1-9]\d{2}|3000)$
PR https://github.com/vyos/vyos-1x/pull/1869
vyos@r14# run show conf com | match ipoe set service ipoe-server authentication mode 'noauth' set service ipoe-server interface eth1 client-subnet '100.64.24.0/24' set service ipoe-server interface eth1 network 'vlan' set service ipoe-server interface eth1 vlan '2000-3000' [edit] vyos@r14#
Check config:
vyos@r14# cat /run/accel-pppd/ipoe.conf | grep "\[ipoe" -A 7 [ipoe] verbose=1 interface=re:eth1\.\d+,shared=0,mode=L2,ifcfg=1,range=100.64.24.0/24,start=dhcpv4,ipv6=1 noauth=1 proxy-arp=1
It is incompatible with static entries.
Maybe it should be fixed after migrating to KEA-DHCP T3316
The similar task T5042
Mar 5 2023
Mar 4 2023
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Mar 3 2023
Needs final testing before PR
https://github.com/vyos/vyos-1x/compare/current...jestabro:literal
it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Possible completions:
<0-4294967295> DHCP lease time in seconds
Standard lease I have in the configuration is "lease 4294967295"
That is a static reservation. Ensures I have the same IP for a specific host.
VyOS 1.3-stable-202303030442 Works as expected
vyos@r1# run show conf com | match open set vpn openconnect authentication mode 'radius' set vpn openconnect authentication radius server 192.168.122.14 key 'vyos-secret' set vpn openconnect listen-ports tcp '4433' set vpn openconnect listen-ports udp '4433' set vpn openconnect network-settings client-ip-settings subnet '100.64.12.0/24' set vpn openconnect ssl ca-cert-file '/config/auth/ca.crt' set vpn openconnect ssl cert-file '/config/auth/server.crt' set vpn openconnect ssl key-file '/config/auth/server.key' [edit] vyos@r1# [edit] vyos@r1# run show version all | match ocser ii ocserv 1.1.6-3 amd64 OpenConnect VPN server compatible with Cisco AnyConnect VPN [edit] vyos@r1# [edit] vyos@r1# run show openconnect-server sessions interface username ip remote IP RX TX state uptime ----------- ---------- ------------- --------------- ------ --------- --------- -------- sslvpn0 foo 100.64.12.225 192.168.122.205 1.3 KB 152 bytes connected 55s [edit] vyos@r1#
PR https://github.com/vyos/vyos-1x/pull/1866
set high-availability vrrp global-parameters notification mail '[email protected]' set high-availability vrrp global-parameters notification send-faults set high-availability vrrp global-parameters notification smtp-server address '127.0.0.1' set high-availability vrrp global-parameters notification smtp-server connection-timeout '30' set high-availability vrrp global-parameters notification smtp-server port '25' set high-availability vrrp global-parameters notification source-mail '[email protected]' set high-availability vrrp global-parameters router-id 'MYROUTER'
In T5048#143916, @Viacheslav wrote:As I understand there no percent or auto and it now expects only rate, needs to check
vyos@r14# set qos policy shaper test default bandwidth Possible completions: <number> Bits per second <number>bit Bits per second <number>kbit Kilobits per second <number>mbit Megabits per second <number>gbit Gigabits per second <number>tbit Terabits per second <number>
I don't know why when I set bandwidth from 10k-10mbit/s, the QoS shaper works correctly but when I set to 100mbit/s~600mbit/s, I only get fews of mbit/s or tens of mbit/s. When I set above about 800mbit/s it looks like no limitation at all. When I manually set limit by tc commands, it seems okay.
As I understand there no percent or auto and it now expects only rate, needs to check
vyos@r14# set qos policy shaper test default bandwidth Possible completions: <number> Bits per second <number>bit Bits per second <number>kbit Kilobits per second <number>mbit Megabits per second <number>gbit Gigabits per second <number>tbit Terabits per second <number>
I don't know why I set a 100mbit/s shaper, but result in lots of retry and 5~10mbit/s speed.
In T5048#143912, @Viacheslav wrote:Try the latest rolling release
@Jimz Which lease time are you useing?
starts 5 2023/03/03 02:09:13; ends never;
With default config I see something like
lease 192.0.2.10 { starts 5 2023/03/03 08:07:15; ends 6 2023/03/04 08:07:15; ...
Try the latest rolling release
I have almost same problem here. Can't NAT between two VRFs correctly. The outgoing packet has been NATed correctly but the incoming packet seems be dropped, can't reach the source, it seems the return packet can't be tracked correctly.
sh dhcp server leases
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/dhcp.py", line 286, in <module> res = vyos.opmode.run(sys.modules[__name__]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 227, in run res = func(**args) ^^^^^^^^^^^^ File "/usr/libexec/vyos/op_mode/dhcp.py", line 246, in _wrapper return func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/libexec/vyos/op_mode/dhcp.py", line 277, in show_server_leases lease_data = _get_raw_server_leases(family=family, pool=pool, sorted=sorted, state=state) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/libexec/vyos/op_mode/dhcp.py", line 85, in _get_raw_server_leases data_lease['end'] = lease.end.timestamp() ^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'timestamp'
After the first lease I got the same error:
Btw, in this rolling release, OSPF BFD in tunnel doesn't work correctly too.
You can manually modify strongswan's systemd service file to add 'ip vrf exec charond'. But it causes other problem.
I backed up /config/dhcpd.leases - replaced it with an empty file. And it appears to be working, the /config/dhcpd.leases file seems to have been corrupted or malformated.
Is there a way to share it privately? It has some of the internal domains and leases.
Mar 2 2023
PR https://github.com/vyos/vyos-1x/pull/1865
We found some issues for the migration and we fixed it on this one.
I was interested in why ping-check is no longer available.
There is a good article about it here:
https://kb.isc.org/docs/why-doesnt-kea-support-ping-check
Have started work on migrating isc-dhcp v4/v6 server to Kea.
In T5041#143810, @fernando wrote:Could we use something like Dannil proposes? https://vyos.dev/T4883 , as you said FRR staticd don't allow this option but it could be useful when we have different mtu over the interface.
Could we use something like Dannil proposes? https://vyos.dev/T4883 , as you said FRR staticd don't allow this option but it could be useful when we have different mtu over the interface.
Cannot reproduce it with this configuration (VyOS 1.4-rolling-202302280651, don't have a lot of file descriptors):
set protocols bfd peer 192.0.2.5 multihop set protocols bfd peer 192.0.2.5 source address '192.0.2.1' set protocols bfd peer 192.0.2.6 multihop set protocols bfd peer 192.0.2.6 source address '192.0.2.1' set protocols bfd profile BBR interval multiplier '3' set protocols bfd profile BBR interval receive '350' set protocols bfd profile BBR interval transmit '350'
The thing is, we don't use iproute2 commands for adding a route. We use FRR staticd for it. As an exception failover route that uses iproute2 commands
FRRouting 8.4.2 doesn't have such option
r14(config)# ip route 192.0.2.1/32 203.0.113.1 <cr> (1-255) Distance value for this route INTERFACE IP gateway interface name dum0 eth0 eth1 eth2 lo veth0 veth1 wg0 Null0 Null interface color SR-TE color label Specify label(s) for this route nexthop-vrf Specify the VRF table Table to configure tag Set tag for this route vrf Specify the VRF
show vpn ipsec remote-access shows only accel-ppp l2tp, pptp https://github.com/vyos/vyos-1x/blob/current/src/op_mode/show_vpn_ra.py
Mar 1 2023
Add another feature that is improved if we're thinking of moving to KEA :