User Details
- User Since
- Jan 18 2019, 4:03 PM (202 w, 3 d)
Tue, Nov 22
This breaks a perfectly valid use case which I use heavily: 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:
[email protected]:~$ 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' [email protected]:~$ configure [edit] [email protected]# set system host-name temp [edit] [email protected]# 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
[email protected]# 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
Jul 7 2021
This is still broken on the most recent rolling release:
[email protected]# 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:
[email protected]# TEST='variable' [edit] [email protected]# set system login user vyos authentication plaintext-password HqNzXaK27k19$TEST [edit] [email protected]# comp [edit system login user vyos authentication] +plaintext-password HqNzXaK27k19variable
@fernando Are you sure you're testing this on 1.3?
[email protected]# run show ver
Jun 20 2021
Yes, though the error has changed:
[email protected]# 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
Jun 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:
[email protected]# 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] [email protected]# run show ver
I 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:
[email protected]# 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:
[email protected]:~# 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 [email protected]:~# 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:
[email protected]:~$ restart flow-accounting [email protected]:~$ 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!
[email protected]:~$ 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:
[email protected]# 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 route
Sep 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.