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 .

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 'destination@bar.local'
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 'foo@bar.local'
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.

PR https://github.com/vyos/vyos-1x/pull/1865
We found some issues for the migration and we fixed it on this one.

PR: https://github.com/vyos/vyos-1x/pull/1863

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.

possible reason https://github.com/vyos/vyos-1x/commit/3bad1d0adb1c187f6611f4bed3d0ad16927d5d18

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

Add another feature that is improved if we're thinking of moving to KEA :

PR:
https://github.com/vyos/vyos-1x/pull/1862

Currently digging through a bug with ocserv upstream maintainers, might get a 1.1.7 once we fix that or atleast a 1.1.6-4.
Aside from the weird Duo+RADIUS thing, the version noted in this issue currently runs great.

My Xbox One game console is set to use "automatic" settings regarding both port selection and forwarding (via UPNP), and in doing so it chose port 54060 on my LAN (and has been distributed the IP address 172.23.217.102 from my DHCP server — which is not VyOS, by the way).

A few issues I'm encountering while trying to test it right now:

PR for 1.3 https://github.com/vyos/vyos-build/pull/316