@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:
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:
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.
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
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!'
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