I checked 6 routers, 2 showed the issue. No idea what the impact is. All of them running 1.3.2.

Maybe this [a-zA-Z_](?:[a-zA-Z0-9_\-\.]{0,}[a-zA-Z0-9_\-])?

I have the correct host-name after reboot

vyos@r14:~$ 
vyos@r14:~$ vtysh -c "show run" | match host
hostname r14
vyos@r14:~$ 
vyos@r14:~$ 
vyos@r14:~$ show ver
Version:          VyOS 1.4-rolling-202305260317
Release train:    current

Draft PR https://github.com/vyos/vyos-1x/pull/2020
Another solution https://github.com/sever-sever/vyos-1x/commit/6f0dadef7ffa64472a98d8614a69538230b2b10d#diff-a4d8965b41a529a70fe69baf25f8413122f3b686ce0b9fe5f9033b4792f4d475
PR https://github.com/vyos/vyos-1x/pull/2022

@zsdc I built the image now, and it works as expected. The issue looks resolved. Thank you.

@dutty can you try to build an image again and check now?

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

PR for VyOS 1.3 LTS branch https://github.com/vyos/vyos-1x/pull/2019

Yes, T4737 looks the same.

In T5243#149267, @Viacheslav wrote:

Maybe the related bug described in T4737
Could you show a version of FRR?

show version all | match frr

Maybe the related bug described in T4737
Could you show a version of FRR?

show version all | match frr

In T970#149229, @olivier.hault wrote:

How far are we in the testing of this important feature ?

Added extension and example for test_vif_8021q_mtu_limits.

One fix added; I'm looking at an extension for the case of test_vif_8021q_mtu_limits, as mentioned in the comment in base_interfaces_test.py.

Let me cherry-pick these and commit all at one

I discovered that conntrack are enabled by default in two files:

Example implementation:
https://github.com/vyos/vyos-1x/compare/current...jestabro:cli-defined

How far are we in the testing of this important feature ?

All of the modem specific settings appear to be done through the web GUI of the modem.

I could have sworn it took quite a while for the wlb.out to be populated when testing earlier on. However as I´ve built out the config a bit more I am now only able to reproduce it a few seconds after reboot - so your theory holds. Let's close out the bug report for now and I´ll reopen if something changes down the line.

Virtual-ethernet interfaces veth implemented in T4825
For veth in "netns" it should be a separate task.

I can't reproduce it VyOS 1.4-rolling-202305250317

set load-balancing wan flush-connections
set load-balancing wan interface-health eth0 failure-count '3'
set load-balancing wan interface-health eth0 nexthop '192.168.122.1'
set load-balancing wan interface-health eth0 success-count '5'
set load-balancing wan interface-health eth0 test 1 target '1.1.1.1'
set load-balancing wan interface-health eth0 test 2 target '8.8.8.8'
set load-balancing wan interface-health eth2 failure-count '10'
set load-balancing wan interface-health eth2 nexthop 'dhcp'
set load-balancing wan interface-health eth2 success-count '10'
set load-balancing wan interface-health eth2 test 1 target '1.1.1.1'
set load-balancing wan interface-health eth2 test 2 target '8.8.8.8'
set load-balancing wan rule 1 failover
set load-balancing wan rule 1 inbound-interface 'eth1.10'
set load-balancing wan rule 1 interface eth0 weight '100'
set load-balancing wan rule 1 interface eth2 weight '10'

Thanks Viacheslav , for this clarification . Veths /Netns are strong powerful , using this technology we can use to join different hypervisor or bridge technology . leave some example namespaces /veth / bridging.

Sorry to write on a closed task, but without specifying a vrf (or some kind of identifier for that matter), how will the DHCP server decide which shared network to use since they have identical subnets configured?