Install official pkg solve the issue

wget http://ftp.de.debian.org/debian/pool/main/o/ocserv/ocserv_0.12.2-3_amd64.deb
dpkg -i *.deb
`

Can be related
Found out some strange things, client address was banned:

ocserv[2072]: main: added 1 points (total 1) for IP '192.168.122.1' to ban list

I don't see any issues with LTS 1.3.0

Thanks
Is it required point of binding in a container?
For example:

podman run --rm -it --device=/dev/vdb:/dev/xvdc:rwm --net host ubuntu bash

In T4249#118633, @Viacheslav wrote:

You can get access to host netwoks with set container name foo allow-host-networks

You can get access to host netwoks with set container name foo allow-host-networks

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1224

@anthr76 we have ready telegraf exporter, maybe it will work for you?
https://docs.vyos.io/en/latest/configuration/service/monitoring.html

Does anyone at least have an example of how to use the snmp exporter? For example a snmp.yml or generate one with the given mibs?

Tested on 1.4-rolling-202202150317 and 1.3.0, all works

this is very similar to https://phabricator.vyos.net/T3657 , so it seems that this is going to be fixed in 1.4 ( proof https://forum.vyos.io/t/bgp-peering-with-ipv6-link-local-addresses/7309/14 ). Is this going to be backported to 1.3 ? Anyone is able to find the commit that introduced the feature on 1.4? Maybe it is something easy to patch

I think @c-po has started migrating it in T3579 but op-mode not yet complete.

Comman "show conntrack ..." not available any more in latest?

Duplicate T1292 was assigned to 1.4 version, and I close it because it was solved.
This bug remains open for 1.3 Equuleus

Tested on VyOS 1.4-rolling-202202150317 and working as expected.

Solved. New commands:

PR for current https://github.com/vyos/vyos-1x/pull/1223

PR for equuleus https://github.com/vyos/vyos-1x/pull/1222

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1221

Sorry, it works properly only for not PD. Looks like is not backported to equuleus
Client-side configuration to reproduce

set interfaces ethernet eth0 address 'dhcpv6'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 address '1'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 sla-id '0'
set interfaces ethernet eth0 dhcpv6-options pd 0 length '64'

On server-side we get the same backtrace

vyos@vyos# run show dhcpv6 server leases 
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 209, in <module>
    leases = get_leases(conf, lease_file, args.state, args.pool, args.sort)
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 142, in get_leases
    leases = sorted(leases, key = lambda k: int(ip_address(k['ip'])))
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 142, in <lambda>
    leases = sorted(leases, key = lambda k: int(ip_address(k['ip'])))
  File "/usr/lib/python3.7/ipaddress.py", line 54, in ip_address
    address)
ValueError: '2001:db8:290::/64' does not appear to be an IPv4 or IPv6 address

Tested on VyOS version 1.3.0, works properly

vyos@vyos# run show version | match Version
Version:          VyOS 1.3.0
[edit]
vyos@vyos# run show dhcpv6 server leases 
IPv6 address        State    Last communication    Lease expiration     Remaining    Type           Pool         IAID_DUID
------------------  -------  --------------------  -------------------  -----------  -------------  -----------  -----------------------------------------------------------------
2001:db8:3456::187  active   2022/02/15 09:28:10   2022/02/15 21:28:10  11:58:28     non-temporary  VyOS-DHCPv6  00:00:00:00:00:04:79:76:62:99:23:ad:43:fb:9c:5b:1c:1e:59:4b:58:01

Hi @hensur , I'm sure that this code should be moved to python implementation, patches for the legacy vyatta-cfg-qos will be rejected.
First of all, need to create CLI XML definition
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#xml-used-for-cli-definitions
and then create backend in python to process CLI commands
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#configuration-script-structure-and-behaviour

I can confirm that the latest 202202140317 build fixes this issue, thanks.

Alternatively, since the pki code seems to already recognize parents/issuers:

I've submitted a PR to fix this here: https://github.com/vyos/vyos-1x/pull/1220

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

@n.fort it is possible with conntrackd logging option syslog

sudo rm /etc/systemd/system/conntrackd.service.d/override.conf

edit nano /etc/conntrackd/conntrackd.conf and add Syslog on in General section, then restart conntrackd service.
After that you will get messages

conntrack-tools[5097]: udp      17 src=100.64.0.3 dst=1.1.1.1 sport=41900 dport=53 src=1.1.1.1 dst=198.51.100.1 sport=53 dport=41900

I'd like to see cake in vyos as well. I don't think this has been implemented yet (at least not under the traffic-policy section in 1.4-rolling) ?

In hosts we can see 2 entries:

vyos@r11-roll# run show conf com | match test
set system static-host-mapping host-name test1.com inet '1.1.1.1'
set system static-host-mapping host-name test2.com inet '2a00:1450:400f:802::200e'

Task for kea T3316

@sever https://kea.readthedocs.io/en/kea-2.0.1/arm/dhcp4-srv.html#using-a-specific-relay-agent-for-a-subnet

@Viacheslav Working on it, should be ready soon.

I think it is necessary to show this kind information . it should use tools/service as netflow/ipfix . for example:

works as expected:

sure, I'll test 1.4 rolling
but if this feature simply adds "dev XXX" to virtual_address in vrrp config that shouldn't break much

@Alexey.Kirillov it required more tests and responses from 1.4
Could you test it?

I can't get your configuration, how does should work without the declaration source or remote address?

I think I'm experiencing this same issue. I just tried upgrading a VPN server running 1.3-rolling-202001260217 to 1.3.0 LTS. As this is a production server (albeit a secondary/backup server) I've reverted to the old version of VyOS, and it looks like a fix is already on its way, so I just wanted to add my info to the ticket.

Is there any chance to backport this to 1.3x ?
It makes migration from cluster way easier.