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

Another good thing is that any logging can be done without spoling the user/pass which otherwise is the case with todays oneliner approach.

It also doesn't appear to accept %, *, or ^ in the password. Perhaps we should consider splitting this up into something like:

set system config-management commit-archive location SERVER1 protocol sftp
set system config-management commit-archive location SERVER1 path '/wdc07/cr01b-vyos'
set system config-management commit-archive location SERVER1 host 'stor01a-rh9.int.trae32566.org'
set system config-management commit-archive location SERVER1 user 'myuser'
set system config-management commit-archive location SERVER1 password '$P4SsW0RD!'

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

Agreed, if it had migrated correctly, I'd see new entries under protocols static; however, the config comparison I posted doesn't have those replacement entries, and my ipv6 (lack of) connectivity confirms it didn't migrate as expected.

I think this is happening because in 1.3, interface-based static routes are under protocols static interface-route6, whereas in 1.4+, they're located in protocols static route6 <address> interface

Fix linked task.

Closed; work continues in T5528.

Working on latest 1.4! 👍

Working on latest 1.4! 👍

Working on latest 1.4. 👍

It will be included after 1.4-rc2

In T5247#166517, @SrividyaA wrote:

Now we receive this error in 1.5-rolling-202312060024 when the command is executed:

vyos@R1:~$ show interfaces system
-vbash: /opt/vyatta/bin/vyatta-show-interfaces: No such file or directory

Just wanted to add that this error is also present in V1.4 RC1

Create a new feature request if you need some specific feature/features
For example, for offloads we use:

vyos@r4# set interfaces ethernet eth0 offload 
Possible completions:
   gro                  Enable Generic Receive Offload
   gso                  Enable Generic Segmentation Offload
   hw-tc-offload        Enable Hardware Flow Offload
   lro                  Enable Large Receive Offload
   rfs                  Enable Receive Flow Steering
   rps                  Enable Receive Packet Steering
   sg                   Enable Scatter-Gather
   tso                  Enable TCP Segmentation Offloading

(edited above for formatting)

I think that this should be addressed at the specific migration script:
https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/nat/5-to-6
Although there are open questions about avoiding migration, and specific ways to avoid it (boot flag 'no-vyos-migrate'), neither are the issue here: migration scripts should 'do no harm', and one invariant that can be enforced is that migration scripts should be idempotent; the above is not, as a result of:
https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/nat/5-to-6#L53-L55
I suggest the patch below to restore idempotency (which clearly can't break anything, since one would not have an empty string as inbound/outbound-interface); thoughts ?

@greywolfe You probably need to use -e without_login=true option. Could you re-check?