User Details
- User Since
- Jan 18 2019, 4:03 PM (144 w, 4 d)
Sat, Oct 23
Thu, Oct 14
Sat, Oct 9
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 descriptorJun 16 2021
Jun 12 2021
This appears to be fixed in the most recent rolling releases; I'm not sure how, but it's fixed.
Jun 11 2021
This does not appear to be fixed; I think it's something specific to 1.4:
trae@cr01a-vyos# commit
Using source address fd52:d62e:8011:fffe:192:168:253:2
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 287, 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 166, in upload_sftp
transfer_sftp('upload', *args, **kwargs)
File "/usr/lib/python3/dist-packages/vyos/remote.py", line 162, in transfer_sftp
sock.shutdown()
TypeError: shutdown() takes exactly one argument (0 given)
[edit policy route-map BGP-BACKBONE-OUT]
trae@cr01a-vyos# run show verI have a similar problem, but different, in T3563. I've reopened it and added information, but basically 1.4 still has the issue reported in that bug report.
Jun 10 2021
Again, the problem is not the time it takes to commit, but the time it takes to set. I will try reproducing it again and see if I can come up with an easier way. I would suggest trying adding the BGP config and prefix lists and route-maps without the export route-map applied, then commit, then try applying the export route-maps.
FRR appears to have no problems processing this extremely quickly:
vyos@cr01b-vyos# time vtysh -c "conf t" -c "router bgp 4242420670" -c "address-family ipv4 unicast" -c "neighbor BACKBONE route-map BGP-BACKBONE-OUT out"
Jun 9 2021
I'm wondering if perhaps it's my prefix lists or route-maps maybe? I can upload those in a bit once I test how fast / slow it is in frr.
Jun 7 2021
This is indeed fixed!
May 23 2021
May 20 2021
Mar 27 2021
Mar 3 2021
I've had this bite me a few times now as well, but I wasn't able to pin it down before to being a bug.
Mar 2 2021
Feb 15 2021
Jan 22 2021
Jan 18 2021
Interesting. I agree, I think that defeats the purpose of VRRP if both have to be running. I guess we can go ahead and close this as not feasible at this time.
Jan 15 2021
This can be fixed by copying the two profile directories you're using (/usr/lib/tuned/network-throughput and /usr/lib/tuned/network-latency) to /etc/tuned and changing the sysctl section to only contain enabled=false. Here's it working:
root@cr01a-vyos:~# diff /usr/lib/tuned/network-latency/tuned.conf /etc/tuned/network-latency/tuned.conf 13,16c13 < net.core.busy_read=50 < net.core.busy_poll=50 < net.ipv4.tcp_fastopen=3 < kernel.numa_balancing=0 --- > enabled=false root@cr01a-vyos:~# diff /usr/lib/tuned/network-throughput/tuned.conf /etc/tuned/network-throughput/tuned.conf 10,16c10 < # Increase kernel buffer size maximums. Currently this seems only necessary at 40Gb speeds. < # < # The buffer tuning values below do not account for any potential hugepage allocation. < # Ensure that you do not oversubscribe system memory. < net.ipv4.tcp_rmem="4096 87380 16777216" < net.ipv4.tcp_wmem="4096 16384 16777216" < net.ipv4.udp_mem="3145728 4194304 16777216" --- > enabled=false
Jan 14 2021
Yep, I use RADIUS.
Jan 9 2021
This is fixed:
trae@cr01b-vyos:~$ restart flow-accounting trae@cr01b-vyos:~$ show ver
Jan 7 2021
Jan 6 2021
Nov 3 2020
Yes! Turns out the following is what fixed it:
https://phabricator.vyos.net/T2980
Oct 26 2020
All of ours do as far as I know, which includes 10,40, and 100g. I'm pretty sure 2.5g and 5g will as well.
Oct 18 2020
Works for me!
trae@cr01b-vyos:~$ show protocols bfd peers Session count: 11 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3776760774 192.168.253.3 192.168.253.7 up 1851352402 fd52:d62e:8011:fffe:192:168:253:3 fd52:d62e:8011:fffe:192:168:253:6 up 3344115206 192.168.253.3 192.168.253.2 down 1252680903 fd52:d62e:8011:fffe:192:168:253:3 fd52:d62e:8011:fffe:192:168:253:2 down 3664188082 192.168.253.3 192.168.253.6 up 2809207409 fd52:d62e:8011:fffe:192:168:253:3 fd52:d62e:8011:fffe:192:168:253:1 up 2086113021 192.168.253.3 192.168.253.12 up 1362288442 unknown fd52:d62e:8011:fffe:192:168:253:12 down 3846665654 fd52:d62e:8011:fffe:192:168:253:3 fd52:d62e:8011:fffe:192:168:253:7 up 276439511 fd52:d62e:8011:fffe:192:168:253:3 fd52:d62e:8011:fffe:192:168:253:12 down 1342044518 192.168.253.3 192.168.253.1 up
Oct 16 2020
That sounds great to me! I actually like that more.
Oct 15 2020
awesome, thanks!
Oct 13 2020
Oct 12 2020
Oct 7 2020
Oct 6 2020
Sep 12 2020
Try a show ipv6 route ospfand look at the routes; they're probably being rejected:
trae@cr01b-vyos# run show ipv ro ospf
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected routeSep 7 2020
Jul 12 2020
Jul 8 2020
Can regression testing of some sort be added for this? I've seen this issue crop up before now, so I would guess this is a good candidate for that if possible.
Closed - this is available as set system ip layer4-hashing
Oh, neat. Thanks, I'll close this then!
Jul 7 2020
Jul 4 2020
Jun 25 2020
This appears to be caused by the setting of service ssh listen-address; it appears the script generating the config is omitting the actual address. Removing a specific listening address is a temporary workaround.
May 16 2020
May 13 2020
Actually I think this is a result of T2434 since the source interface is bond1, so I'm closing this again. My apologies.
@jjakob This doesn't appear to have been fixed in VyOS 1.3-rolling-202005130117