User Details
- User Since
- Jan 18 2019, 4:03 PM (310 w, 2 d)
Wed, Dec 4
This works!:
trae@cr01b-vyos# set pki ca IPA.TRAE32566.ORG system-install [edit] trae@cr01b-vyos# commit Archiving config... sftp://stor01a-rh9.int.trae32566.org/int/cr01b-vyos [edit] trae@cr01b-vyos# run restart ntp [edit] trae@cr01b-vyos# run show ntp sources .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / 'x' = may be in error, '~' = too variable, '?' = unusable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* ns02.ac.trae32566.org 2 6 7 0 +2ns[ -188ms] +/- 5513us ^- ns01.ac.trae32566.org 2 6 7 0 +120us[ -188ms] +/- 5598us
Nov 1 2024
I think @Viacheslav is right here, I added the ethernet interfaces instead and now it works. I guess maybe add something that prevents adding bonds to flowtable, and instead directs the user to add the member interfaces?
Oct 31 2024
Oct 24 2024
Personally, I would just create a directory in /usr/local/share/ca-certificates/ for each CA certificate named the same as that part of the config node (ex: IPA.TRAE32566.ORG in my example), then run update-ca-certificates...I just don't know how to implement this myself.
Oct 15 2024
@c-po So what's interesting here is it seems like it might be something with the reconfiguration of the daemon. Try deleting and then adding the default config, like this (obviously after delete service ntp and commit):
vyos@cr01-vyos# set service ntp allow-client address 127.0.0.0/8 [edit] vyos@cr01-vyos# set service ntp allow-client address 169.254.0.0/16 [edit] vyos@cr01-vyos# set service ntp allow-client address 10.0.0.0/8 [edit] vyos@cr01-vyos# set service ntp allow-client address 172.16.0.0/12 [edit] vyos@cr01-vyos# set service ntp allow-client address 192.168.0.0/16 [edit] vyos@cr01-vyos# set service ntp allow-client address ::1/128 [edit] vyos@cr01-vyos# set service ntp allow-client address fe80::/10 [edit] vyos@cr01-vyos# set service ntp allow-client address fc00::/7 [edit] vyos@cr01-vyos# [edit] vyos@cr01-vyos# set service ntp server time1.vyos.net [edit] vyos@cr01-vyos# set service ntp server time2.vyos.net [edit] vyos@cr01-vyos# set service ntp server time3.vyos.net [edit] vyos@cr01-vyos# commit Archiving config... sftp://stor01a-rh9.int.trae32566.org/bhs/cr01-vyos Host 'stor01a-rh9.int.trae32566.org' not found in known hosts. Fingerprint: 1083a0c4ff8380df83596781bcddf2a9 Do you wish to continue? [y/N] y
Sep 30 2024
Sep 28 2024
Sep 25 2024
Sep 12 2024
Sep 11 2024
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 (tsantiago@us.ibm.com) 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 firewall
Feb 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:PASS@stor01z-rh8.int.trae32566.org:/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 10000