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.

@Viacheslav As I said: every rolling version of VyOS 1.3 branch starting from mid-January. I built ISO several times during this month. Last one I tried today (built today). All of them behave like this in my two different routers. Last time ocserv worked was middle of December build.

Which version?

@Scoopta Can you check your configuration with the next rolling release?

@hensur Could you create a PR for 1.3?

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

Checked in VyOS 1.3-stable-202202101926

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