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

I've traced the issue back to a USB device that creates an Ethernet interface on the OS. I suspect that the issue was caused by the USB device not being ready by the time ddclient tried to start and bind to configured interfaces, causing the boot time configuration to fail. Given that this is an edge case that would rarely occur, and now that I have replaced the USB device with an actual Ethernet device, I'm happy to close this bug report.

Deprecated commands are deleted.
It should be reimplemented if it is needed in a separate feature request/task

PR https://github.com/vyos/vyos-1x/pull/2852 basic implementation

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

Will be fixed in 1.4.0-rc3

After some research, I have concluded that the error was caused by the string's violation of RFC 3986, which recommends using percent encoding instead. I'll look into the feasibility of implementing percent encoding/decoding (which urllib natively supports) for spicy characters if there's demand, but the recommended method in VyOS right now is using the protocol-agnostic REMOTE_USERNAME and REMOTE_PASSWORD environment variables, which bypass the URL decoding step. The alternative would involve messing with urllib.parse's internal parser to implement a laxer and less greedy regexp to accept passwords like this, which is probably a bad idea.

What are you expecting

This should pretty much explain it

Let's not close it now, as we do not fully understand the cause

That doesn't seem to insert missing leaf nodes, so I rebuilt the installation by copy/paste of commands from existing VM, and it migrated the routes as expected upon upgrade to 1.4-rc2.

See https://vyos.dev/T5958

It causes the issue with no qos config after update (from 1.3.5)
Before migration

set traffic-policy shaper-hfsc SHAPE-10mbit bandwidth '400mbit'
set traffic-policy shaper-hfsc SHAPE-10mbit class 10 linkshare m2 '200mbit'
set traffic-policy shaper-hfsc SHAPE-10mbit class 10 match MARK mark '10'
set traffic-policy shaper-hfsc SHAPE-10mbit default linkshare m2 '200mbit'

Incorrect firewall setting block the communication

We agree not to implement this, at least in the proposed format.
Close it as wontfix.

In T5947#172846, @kevinrausch wrote:

Well, it didn't start on 1.3.2, so I don't know how the empty leaf nodes could have disappeared over time.

Is there a way to force a full rewrite of the config.boot before attempting upgrades?

I can not reproduce it with the above commands. Even not getting any IP address on the DHCP interface lets ddclient start

Well, it didn't start on 1.3.2, so I don't know how the empty leaf nodes could have disappeared over time.

Your original config looks corrupted.
For example
Loopback entry:

loopback lo

Expected entry:

loopback lo {
}

So, the problem seems to be with empty leaf nodes missing from my baseline config.

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

@Daya @trae32566 Is it not the issue anymore?

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.

@Viacheslav tested and confirmed fixed in RC2.

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

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

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.