Sounds like a great solution to me, happy to review your PR.

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

Sample config files here: https://github.com/networkupstools/nut/tree/master/conf

I think there are actually two aspects here.

In rVYOSONEXee494c3a1dbfca3457bcaffe89d45971348e4848#958480, @workingagain wrote:

In rVYOSONEXee494c3a1dbfca3457bcaffe89d45971348e4848#958479, @sdev wrote:

Are you able to provide the dhcp config that fails migration? I wasn't able to re-create any migration problem in my tests

set service dhcp-server hostfile-update
set service dhcp-server shared-network-name LAN option name-server '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option domain-name 'localdomain'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start '192.168.1.9'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop '192.168.1.254'

same as whats in the old quickstart guide

Sure. I did some further testing and it looks like this is triggered if the client sends DHCP option 81 (FQDN). To reproduce:

Which user are you expecting? Hows to check from which user container was started?
Any idea for CLI?

@kevinrausch I cannot reproduce it, all works fine.
before update

vyos@r1# run show conf com | match route6
set protocols static interface-route6 2001:db8::/64 next-hop-interface lo
set protocols static table 10 interface-route6 2001:db8::/64 next-hop-interface tun0
set protocols static table 20 interface-route6 2001:db8::/64 next-hop-interface tun1
[edit]
vyos@r1# 
[edit]
vyos@r1# run show version

Performed these steps:

• clean, checkout 1.3.5, build, push to internal web host
• rollback VM to 1.3.2 working baseline
• save vyos132.cfg
• add system image https://removed/vyos-1.3.5-private-amd64.iso
• reboot
• compare 1, no changes to config as expected
• add system image https://cdn.vyos.io/1.4.0-rc1/vyos-1.4.0-rc1-amd64.iso
• reboot
• compare 1, confirm routes dropped per T5947 description
• load vyos132.cfg
• compare 1, observe routes have been migrated as expected, below

1.4.0-rc2 also has opennhrp service stop after vyos startup. Can you please add a 1.4 tag to this issue?

@Daya @trae32566 Is it not the issue anymore?

I'd tag it as wontfix

Domain name was never configured for FRR in our templates

r4# conf t
r4(config)# domainname 
  WORD  This system's domain name
r4(config)#

Seems fixed:
Before reboot:

set interfaces ethernet eth1 description 'LAN'
set interfaces ethernet eth1 hw-id '52:54:00:04:33:2b'
set interfaces ethernet eth1 vif 20 address 'dhcp'
set interfaces ethernet eth1 vif 20 disable

Fixed for both VyOS 1.5-rolling-202401140026 and VyOS 1.4.0-rc2

I'm against this implementation. We agree do not use boolean values yes|no enable|disable on|off
It will add more mess than usefulness. Configuring features in 2-3 places is a bad idea!
What will be if I add "ssh server" ? Which port will it see? Does it allow all addresses to ssh? What sense in this rule?
The same goes for VRRP; which addresses will it use? Multicast/unicast?
And there are also questions about priorities and what to do it it is accepted via this feature and dropped by a regular firewall.

@Nova_Logic Describe what exactly you want to do
Policy and firewalling are possible now

vyos@r4# set firewall ipv4 input filter rule 10 inbound-interface name eth1.v10
[edit]
vyos@r4# set policy route foo interface eth1.v10
[edit]
vyos@r4#

Personally I would prefer that the "automagic" firewall ruleset would be done optionally through method described in:

@Viacheslav tested and confirmed fixed in RC2.

@giga1699 it was merged on Dec 12, 2023 https://github.com/vyos/vyos-1x/commit/b149a386400c0f869654ac26b0fee2e7f1bbc282
after building 1.3.5 Built on: Mon 04 Dec 2023 21:36 UTC

Good practise add a set of the commands to reproduce
Thanks

I've done more investigation of this issue today, and I believe I understand the cause.

I've found some time to do some work on a fork of vyos-1x. I have a working patch to 1.5-rolling that does the following:

I am facing same issue here.
In my case, My laptop hostname is cn002472.xxx.com

I lost my legacy LTS access, so I'll have to build 1.3-latest to test that.

I'd be curious if updating to 1.3.5 first, then moving to 1.4 has any impact on this issue. I only say this because I have two separate routers I just upgraded from 1.3.5 that both have the following (after upgrade) which looks to have been correctly migrated:

route6 ::/0 {
    next-hop 2001:db8:3a01:a5::1 {
    }
}
route6 2001:db8:3a01:2::/64 {
    blackhole {
    }
}
route6 2001:db8:3a01:c5::/64 {
    interface bond1.1258 {
    }
}
route6 2001:db8:3a01:fd::/64 {
    interface bond1.1258 {
    }
}
route6 fc00::/7 {
    blackhole {
    }
}
route6 2001:db8:8011:239d::/64 {
    interface bond0.925 {
    }
}

Performed these steps:

• rollback VM to 1.3.2 working baseline
• save vyos132.cfg
• add system image https://cdn.vyos.io/1.4.0-rc1/vyos-1.4.0-rc1-amd64.iso
• reboot
• compare 1, confirm routes dropped per T5947 description
• load vyos132.cfg
• compare 1, observe routes have been migrated as expected, below

I just tested in 1.3.5, and I’m getting the same error.

Works fine

vyos@ci-router1:~$ cat /var/log/cloud-init-output.log 
Cloud-init v. 22.1-437-g3e026561-1~bddeb running 'init-local' at Tue, 16 Jan 2024 15:08:04 +0000. Up 17.93 seconds.
Cloud-init v. 22.1-437-g3e026561-1~bddeb running 'init' at Tue, 16 Jan 2024 15:08:09 +0000. Up 21.96 seconds.
ci-info: ++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++
ci-info: +--------+------+-----------------+---------------+--------+-------------------+
ci-info: | Device |  Up  |     Address     |      Mask     | Scope  |     Hw-Address    |
ci-info: +--------+------+-----------------+---------------+--------+-------------------+
ci-info: |  eth0  | True | 192.168.122.172 | 255.255.255.0 | global | 52:54:00:e3:4f:82 |
ci-info: |   lo   | True |    127.0.0.1    |   255.0.0.0   |  host  |         .         |
ci-info: |   lo   | True |     ::1/128     |       .       |  host  |         .         |
ci-info: +--------+------+-----------------+---------------+--------+-------------------+
ci-info: +++++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++++
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: | Route |  Destination  |    Gateway    |    Genmask    | Interface | Flags |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: |   0   |    0.0.0.0    | 192.168.122.1 |    0.0.0.0    |    eth0   |   UG  |
ci-info: |   1   | 192.168.122.0 |    0.0.0.0    | 255.255.255.0 |    eth0   |   U   |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: |   1   |  multicast  |    ::   |    eth0   |   U   |
ci-info: +-------+-------------+---------+-----------+-------+
Cloud-init v. 22.1-437-g3e026561-1~bddeb running 'modules:config' at Tue, 16 Jan 2024 15:08:10 +0000. Up 23.28 seconds.
Killed old client process
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Upon closer inspection, it seems neither #36 nor $37 actually solve the problem.

https://github.com/vyos/vyos-1x/pull/2834

With 1.4.0-rc1 All OK, came up on reboot:

Could you get the original 1.3.x config file copy to the 1.4 instance and load config? I tested 1.3.5 looks good

load path_to_config_1.3

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