User Details
- User Since
- Jan 18 2019, 4:03 PM (299 w, 1 h)
Mon, Sep 30
Sat, Sep 28
Wed, Sep 25
Thu, Sep 12
Wed, Sep 11
Sep 9 2024
Jun 6 2024
@Viacheslav sorry, for some reason I didn't see this until now. I actually moved the routers to 1.4-epa3 to test whether it occurs on that version, and it does. Here are my conntrack stats after a week on 1.4-epa3 (note that I haven't started seeing connectivity issues yet, but I imagine I will in the next few days once I hit the limit):
trae@cr01a-vyos:~$ show conntrack-sync statist cache internal: current active connections: 403218 connections created: 4998006 failed: 0 connections updated: 11289840 failed: 0 connections destroyed: 4594788 failed: 0
May 9 2024
I think this was resolved at some point, but I ended up removing it (the accept-protocol stuff) from my config since it didn't appear necessary and was causing issues, so I'm not certain.
Mar 17 2024
Here's the generated configuration from /run/conntrackd/conntrackd.conf:
# Synchronizer settings
Sync {
Mode FTFW {
DisableExternalCache on
}
Multicast {
IPv4_address 225.0.0.50
Group 3780
IPv4_interface 192.168.15.3
Interface bond0.110
SndSocketBuffer 104857600
RcvSocketBuffer 104857600
Checksum on
}
}
Helper {
Type rpc inet tcp {
QueueNum 3
Policy rpc {
ExpectMax 1
ExpectTimeout 300
}
}
Type rpc inet udp {
QueueNum 4
Policy rpc {
ExpectMax 1
ExpectTimeout 300
}
}
Type tns inet tcp {
QueueNum 5
Policy tns {
ExpectMax 1
ExpectTimeout 300
}
}
}Feb 25 2024
I would say this would still be useful for c-states, and also for other things, for example setting hugepages, and If I remember right, the VPP addon also requires boot arguments be added.
Jan 22 2024
All you need to do to test it is set interfaces <ifaceClass> <iface> policy , commit, save, and then upgrade from 1.3.5 to 1.4, then this happens:
trae@cr01b-vyos:~$ configure WARNING: There was a config error on boot: saving the configuration now could overwrite data. You may want to check and reload the boot config [edit] trae@cr01b-vyos# comp saved [interfaces bonding bond0] - policy
I feel like maybe it would be a smart move to prune config structures:
- when deleting configuration nodes (ex: If I had a traffic policy set, then ran delete interfaces bonding bond0 vif 123 policy route FOO, make sure to delete the policy section of the configuration assuming there is no route6, not just the route FOO part):
- when upgrading major versions
Yeah I'm migrating everything to 1.4, so I don't need this.
Jan 21 2024
Yes, this is fixed.
Jan 17 2024
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 {
}
}Jan 16 2024
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!'
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
Jan 15 2024
I think I see part of what's happening here; it looks like the format for configuration-sync URIs removed the colon (:) between the host and path:
<PROTO>://<USER>:<PASS>@<HOST>:<PATH>
is now:
<PROTO>://<USER>:<PASS>@<HOST><PATH>
It looks like what this should be converted to is as follows:
trae@cr01b-vyos# show as-path-list
as-path-list DAL10 {
rule 10 {
action permit
description "Allow anything from or via DAL10"
> regex 4242420668_$
}
}
as-path-list IBM {
rule 10 {
action permit
description "Allow anything directly from IBM Cloud"
> regex ^_42424206(68|70)_$
}
}
as-path-list INT {
rule 10 {
action permit
description "Allow anything from or via int"
> regex 4242420666_$
}
}It looks like with VyOS 1.3, one way to match AS path (or at least, the way I did it) was to use an escaped parenthesis [\)], but in 1.4+ it appears this way no longer works, and instead those escapes should probably be converted to underscores (_).
Jan 14 2024
@samip537 You should use the peer group definition inside the v6-only stanza, like so:
neighbor wg1 {
interface {
v6only {
peer-group BACKBONE
remote-as 4242420669
}
}
}Jan 12 2024
My only comment here would be to hesitate when putting in restrictions; as Doug Gwyn once said:
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Jan 10 2024
I tried manually loading this config in a VM and I'm still not sure what's causing the issue, maybe something isn't waiting properly for bonded interfaces to be created?:
vyos@vyos# load config.boot-cr01a-vyos.20240109_232428 Loading configuration from 'config.boot-cr01a-vyos.20240109_232428' Load complete. Use 'commit' to make changes effective. [edit] vyos@vyos# commit
Dec 30 2023
Dec 28 2023
I haven't been able to test beyond 1.5-rolling-202312130023 due to T5863. I'll test it again once I'm able to update to the latest rolling. Thanks!
Yeah I'm having this issue as well:
trae@cr01a-vyos# commit Archiving config... sftp://stor01a-rh9.int.trae32566.org/int/cr01a-vyos FAILED!
Dec 27 2023
Food for thought:
Dec 14 2023
should be fixed by https://github.com/vyos/vyos-1x/pull/2634
Dec 12 2023
This should fix it:
{F4006571}
Sep 18 2023
I haven't tried anything else since I rebooted back into 1.4, but I did try sudo su - which gave the same error.
I think this broke a whole lot of things for RADIUS users (these work fine in 1.4-rolling-202308040317, but are broken in 1.5-rolling-202309170024):
Jul 11 2023
Why is this closed? If you don't want the functionality, fine, but don't leave broken functionality in the installer....at least take it out so you're not confusing your users when it doesn't work.
Jul 9 2023
@Viacheslav So I figured out what's causing it..it looks like for some reason my commit-archive configuration on the secondary side (which works fine normally) is causing the hanging. As soon as I remove the set system config-management commit-archive on the secondary side, everything starts working fine, even with my full firewall configuration. Has this been tested at all with commit-archive? Could there be some sort of bug happening with it? Here's the section of the secondary side config, for reference:
[system config-management]
- commit-archive {
- location "sftp://<someUser>:<somePass>@stor01a-rh9.int.trae32566.org/int/cr01b-vyos"
- source-address "fd52:d62e:8011:fffe::3"
- }Yeah I tried increasing the timeout to the maximum (300) and it still timed out, but I'll try config-sync mode 'set' I guess. The config is fairly large; 549 lines of just set firewall.
@Viacheslav I'm not sure why, but it appears that after doing this, there is high CPU usage on the secondary side, and eventually it stops responding entirely (bgp sessions go down, no response to anything via icmp) and has to be hard reset; it won't even respond to a console login attempt:
@Viacheslav I think that fixed it...sorta. It looks like now it does sync successfully, though it appears to time out after awhile for some reason:
trae@cr01a-vyos:~$ sudo nano -c +140 /run/scripts/commit/post-hooks.d/vyos_config_sync trae@cr01a-vyos:~$ sudo systemctl restart vyos-configd trae@cr01a-vyos:~$ configure [edit] trae@cr01a-vyos# set firewall name INT_TO_LOCAL rule 80 destination address 192.168.253.2-192.168.253.3 [edit] trae@cr01a-vyos# commit INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=cr01b-vyos.int.rtr.trae32566.org
Same version on both, 1.4-rolling-202307070317. Also, if you can disable 2 factor on my Slack account ([email protected]) we can talk in Slack about this (lost my 2 factor app / backup codes).
@Viacheslav
@Viacheslav Thanks for all the work on this, I'm glad to see it moving along! This doesn't appear to work for me on 1.4-rolling-202307070317; I've configured it for both firewall and NAT and it appears to not be getting triggered (though I've only tried firewall changes so far). Here's the primary side (cr01a-vyos.int) config:
trae@cr01a-vyos# show service config-sync
mode load
secondary {
address cr01b-vyos.int.rtr.trae32566.org
key <MyKey>
}
section nat
section firewallFeb 13 2023
Nov 22 2022
This breaks a perfectly valid use case which I utilize regularly: using IPv4 + IPv6 peers with the same public key. Why would I want to create multiple keys for the exact same devices going over IPv4 and IPv6? If you want to include a warning, fine, but don't limit functionality based on someone's interpretation of how something will be used. I understand where this came from, but any time you limit functionality, you limit your users. As Donald Knuth once said:
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Sep 30 2022
Jun 30 2022
This seems to be an issue in 1.4 as well, I have the exact same symptoms, and removing the accept-protocol fixes the issue.
Jun 16 2022
Dec 17 2021
Still broken:
trae@cr01b-vyos:~$ show conf com | grep arch set service dhcp-server shared-network-name INT subnet 192.168.1.0/24 domain-search 'int.trae32566.org' set service dhcp-server shared-network-name INT subnet 192.168.1.0/24 domain-search 'ipa.trae32566.org' set service dhcp-server shared-network-name INT subnet 192.168.1.0/24 domain-search 'trae32566.org' set system config-management commit-archive location 'sftp://USER:[email protected]:/int/cr01b-vyos' set system config-management commit-archive source-address 'lo' set system domain-search domain 'int.trae32566.org' set system domain-search domain 'ipa.trae32566.org' set system domain-search domain 'trae32566.org' trae@cr01b-vyos:~$ configure [edit] trae@cr01b-vyos# set system host-name temp [edit] trae@cr01b-vyos# commit Using source address lo Archiving config... sftp://stor01z-rh8.int.trae32566.org:/int/cr01b-vyos Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3/dist-packages/vyos/remote.py", line 312, in upload urlc(urlstring, *args, **kwargs).upload(local_path) File "/usr/lib/python3/dist-packages/vyos/remote.py", line 202, in upload with self._establish() as ssh, ssh.open_sftp() as sftp: File "/usr/lib/python3/dist-packages/vyos/remote.py", line 189, in _establish sock = socket.create_connection((self.hostname, self.port), socket.getdefaulttimeout(), self.source) File "/usr/lib/python3.9/socket.py", line 843, in create_connection raise err File "/usr/lib/python3.9/socket.py", line 830, in create_connection sock.bind(source_address) socket.gaierror: [Errno -5] No address associated with hostname [edit]
This is on 1.4-rolling-202112160318
Dec 6 2021
I think this actually inadvertently broke things even more, because now:
Nov 20 2021
I think this is what it would look like in service dhcp server. I left some comments to explain my thinking a bit, and I tried to make it as flexible as possible (for example the way match options are strings, so future DHCP options can be supported as soon as ISC supports them):
failover {
name INT
remote 192.168.15.4
source-address 192.168.15.3
status primary
}
shared-network-name INT {
description "Internal connection to ir01"
class CLIENT_MAP {
rule 10 {
action permit # This is equivalent to dhcpd's allow/deny members of
match option "agent.circuit_id" value "Vlan200" # This could match any option (ex: dhcp-client-identifier)
}
}
class GUEST_MAP {
rule 10 {
action permit
match option "agent.circuit_id" value "Vlan240"
}
}
subnet 192.168.1.0/24 {
class CLIENT_MAP
default-router 192.168.1.1
domain-name int.trae32566.org
domain-search int.trae32566.org
domain-search ipa.trae32566.org
domain-search trae32566.org
enable-failover
name-server 192.168.255.1
name-server 192.168.15.10
name-server 192.168.31.3
ntp-server 192.168.255.2
ntp-server 192.168.15.11
ntp-server 192.168.31.4
range CLIENTS {
start 192.168.1.2
stop 192.168.1.240
}
server-identifier 192.168.15.2
static-mapping QUEST {
ip-address 192.168.1.17
mac-address 80:f3:ef:11:e7:e7
}
}
subnet 192.168.6.0/24 {
class GUEST_MAP
default-router 192.168.6.1
enable-failover
name-server 1.1.1.1
name-server 1.0.0.1
name-server 8.8.8.8
ntp-server 50.205.57.38
ntp-server 64.225.34.103
ntp-server 129.250.35.251
server-identifier 192.168.15.2
range GUESTS {
start 192.168.6.2
stop 192.168.6.254
}
}
subnet 192.168.15.0/29 { # This tells it indirectly to use the interface eth2, which is on this subnet (is there a better way?)
default-router 192.168.15.1
enable-failover
range DUMMY {
start 192.168.15.2
stop 192.168.15.7
}
}
}Oct 23 2021
Oct 14 2021
Oct 9 2021
Jul 8 2021
trae@cr01a-vyos# show system config-management
commit-archive {
location sftp://cr01a-vyos.int:<somePassword>@stor01z-rh8.int.trae32566.org:/int/cr01a-vyos
source-address lo
}
commit-revisions 10000Jul 7 2021
This is still broken on the most recent rolling release:
trae@cr01a-vyos# commit
Using source address lo
Archiving config...
sftp://stor01z-rh8.int.trae32566.org:/int/cr01a-vyos Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 315, in upload
upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar)
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 190, in upload_sftp
transfer_sftp('upload', *args, **kwargs)
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 162, in transfer_sftp
sock.connect((hostname, port))
OSError: [Errno 22] Invalid argument
[edit protocols bgp]Jun 23 2021
Jun 22 2021
Confirmed that's what is happening:
vyos@cr01a-vyos# TEST='variable' [edit] vyos@cr01a-vyos# set system login user vyos authentication plaintext-password HqNzXaK27k19$TEST [edit] vyos@cr01a-vyos# comp [edit system login user vyos authentication] +plaintext-password HqNzXaK27k19variable
@fernando Are you sure you're testing this on 1.3?
vyos@cr01a-vyos# run show ver
Jun 20 2021
Yes, though the error has changed:
trae@cr01b-vyos# commit
Using source address fd52:d62e:8011:fffe:192:168:253:3
Archiving config...
sftp://stor01z-rh8.int.trae32566.org:/int/cr01b-vyos Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 299, in upload
upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar)
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 178, in upload_sftp
transfer_sftp('upload', *args, **kwargs)
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 174, in transfer_sftp
sock.shutdown(socket.SHUT_RDWR)
OSError: [Errno 9] Bad file descriptor