Should be fixed
@primoz Could you check it again?

As a workaround, you can try to use the "transition script" to manipulate with interfaces

ISC-DHCP-Server does not support vrf's
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpd

I can't reproduce it

vyos@r14:~$ show conf com | match "vrf|tele"
set interfaces ethernet eth1 vrf 'mgmt'
set service monitoring telegraf influxdb authentication organization 'log@in.local'
set service monitoring telegraf influxdb authentication token 'GuRJc12tIzfjnYdKRAIYbxdWd2aTpOT9PVYNddzDnFV4HkAcD7u7-kndTFXjGuXzJN6TTxmrvPODB4mnFcseDV=='
set service monitoring telegraf influxdb port '8086'
set service monitoring telegraf influxdb url 'https://foo.local'
set service monitoring telegraf prometheus-client
set service monitoring telegraf vrf 'mgmt'
set vrf name mgmt table '1010'
vyos@r14:~$

After reboot, the service telegraf works correctly

vyos@r14:~$ sudo systemctl status telegraf
● telegraf.service - The plugin-driven server agent for reporting metrics into InfluxDB
     Loaded: loaded (/lib/systemd/system/telegraf.service; disabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/telegraf.service.d
             └─10-override.conf
     Active: active (running) since Thu 2022-10-13 15:24:23 EEST; 1min 19s ago
       Docs: https://github.com/influxdata/telegraf
   Main PID: 1868 (telegraf)
      Tasks: 10 (limit: 9404)
     Memory: 54.4M
        CPU: 2.650s
     CGroup: /system.slice/telegraf.service
             └─vrf
               └─mgmt
                 └─1868 /usr/bin/telegraf --config /run/telegraf/telegraf.conf --config-directory /etc/telegraf/telegraf.d --pidfile /run/telegraf/telegraf.pid

KEA DHCP have some hook limitations https://kea.readthedocs.io/en/kea-2.2.0/arm/hooks.html?#available-hook-libraries

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

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

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

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

vyos@r14# commit
[ protocols bgp ]
Ebgp-multihop can not be used with directly connected neighbor "eth0"

That does not change the behavior. I get five messages on session start from bfdd, bgpd, ospfd processes, and 16 messages from all FRR daemons on session stop.
The only way to get rid of them is 'log syslog emergencies' but this filters important events as well.

@aserkin as workaround try to change facility level

vtysh -c "conf t" -c "log facility local0"

But it can affect to bgp logs

+1 for @Viacheslav proposal.

Any suggestions on the problem, guys?
I see a lot of messages regarding these messages appearing in various scenarios since 2017 or even earlier in FRR community. But did not find any solution actually.

@thetooth There is a new feature failover route where you can set metrics
https://github.com/vyos/vyos-1x/pull/1358
It could be extended to some "load-balancing"

I have used this feature in the past but not anymore due to the issues listed in the regressions task. We are now running pfsense purely for LB since this (mostly) works as advertised. Looking back at this current implementation there are some very useful features that are missing.

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

vyos@r14# cat /run/telegraf/telegraf.conf | grep 'inputs.exec' -A 8
[[inputs.exec]]
  commands = [
    "/etc/telegraf/custom_scripts/show_firewall_input_filter.py",
    "/etc/telegraf/custom_scripts/show_interfaces_input_filter.py",
    "/etc/telegraf/custom_scripts/vyos_services_input_filter.py"
  ]
  timeout = "10s"
  data_format = "influx"
[edit]
vyos@r14#

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

I believe the ISC DHCP is now officially deprecated and EOLed:

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

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

vyos@r14:~$ show conntrack table ipv6
Entries not found
vyos@r14:~$

In T4729#135230, @pasik wrote:

Ah, yeah, that's a valid point for gretap.

Anyway, my point was, it would be good to test if the issue/bug also affects plain 'gre', as behind the scenes 'gre' and 'gretap' are handled and configured differently, even though they might seem as very similar in vyos cli/config.

The bug might affect both, but it would be good to check and verify.

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

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

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

zone policy has to be assigned to the firewall rule, that's why the commit failed.

@florin If this is needed I'll make a pull request coming week.

I think this needs to be backported to 1.3 too

I have tested it again. So it happens only if conntrack table is empty.
The same problem with IPv4.

Added PR for this here, https://github.com/vyos/vyos-1x/pull/1574

I implemented address-mask as described above as well: https://github.com/Rain/vyos-1x/commit/ca6b7340714c6161337f508978b9834722be58dc

A separate mask field is cleaner also from a documentation point of view. But how would you do it for an address/network group? It only makes sense for a single address I suppose.

On second thought, maybe instead of supporting the ::beef/::ffff syntax we add an address-mask field to source and destination?

I closed the other PR, and put in https://github.com/vyos/vyos-1x/pull/1572.

I'd like to see this feature added so I went ahead and implemented it: https://github.com/Rain/vyos-1x/commit/975f4fc358f0073f1ad825ea209169766dc2fa51

Working directory here; PR pending:
https://github.com/vyos/vyos-1x/compare/current...jestabro:gql-simplify

This a project for mobile access to enterprise networks. VyOS plays as an MPLS-PE router as well as L2TP Network Server. Every subscriber coming via l2tp is directed to the customer's VRF other than default (with RADIUS attribute)

Hi @aserkin! It looks like you have some frr server misbehavior. It sends up/down events with an unexisting vrf id.
Could you make/describe the setup that causes the issue to appear? Thanks