| It has been made to implement 'free' SDWAN speed-tests on a BGP on loopback design (which does not require any license) with the guidelines in the documentation for another topology: Running speed tests from spokes to the hub in dial-up IPsec tunnels. Dial-up IPsec tunnels are not needed on 'BGP on loopback', so this configuration does not use them. The schema is the next one; in this case, the server is on the Hub, and tests are run from spokes to the Hub: 
On the spoke side, this error can be fixed by debugging: fcron_speedtest_dispatch()-604: root: UL1-H1_ISP1(UL1-H1_ISP1) request token from 172.30.0.253 failed. fcron_speedtest_dispatch()-604: root: UL1-H1_ISP2(UL1-H1_ISP2) request token from 172.30.0.253 failed. fcron_speedtest_arm_sched()-296: Speed test (0xf651830) for UL1-H1_ISP1 will run in 42 s fcron_speedtest_arm_sched()-296: Speed test (0xf6d8dc0) for UL1-H1_ISP2 will run in 42 s And on Hub, this error can also appear: H1 # [speedtest(11397)::serv(0054)] auth result: 3, uuid=34677a72-7135-786c-3365-7165666b7a6e, peerv4=0.0.0.0 [speedtest(11397)::serv(0192)] test failed: unauthorized test(142) [speedtest(11397)] server listening on 5201 (fd=5) This is due to the authorization token on the Hub side not being set for the communication between the spoke and the hub. This is a requirement on the control plane to do the test itself. On spoke and on hub, only traffic going through the 'BGP on loopback' interfaces is seen with no answer from the Hub side. For instance, on Hub: 2026-01-27 12:51:06.460618 EDGE_ISP1 in 172.30.0.1.9102 -> 172.30.0.253.5200: udp 32
2026-01-27 12:51:11.457918 EDGE_ISP1 in 172.30.0.1.9102 -> 172.30.0.253.5200: udp 32
2026-01-27 12:51:16.454653 EDGE_ISP1 in 172.30.0.1.9102 -> 172.30.0.253.5200: udp 32
2026-01-27 12:51:21.456538 EDGE_ISP1 in 172.30.0.1.9102 -> 172.30.0.253.5200: udp 32 The reason why this authorization failure appears is that on BGP on loopback, the IPs used for the authorization phase are the BGP on loopback ones, as tunnels do not have IP addressing, and this flow requires a firewall policy on the server side. Traffic flows from the overlay to the 'BGP on loopback' interface on the Hub on port 5200, which is not allowed on the Hub. The firewall policy to configure is: 
As well as the policy, port 5200 must be open on BGP on loopback, which requires 'speed-test' permission on it. After port 5200 communication is allowed, it will succeed, and no authorization failure will appear. Following this, a communication on port 5201 between the IP of the underlay interfaces to reach the 'destination server' appears. In this case, the route to reach 'destination server' (198.38.101.100 on wan1 Hub interface) through the overlay uses the IP of the underlay interface holding that overlay: 2026-01-27 18:37:10.504636 port1 out 198.38.11.1.16053 -> 198.38.101.100.5201: udp 1460
2026-01-27 18:37:10.504639 port1 out 198.38.11.1.16053 -> 198.38.101.100.5201: udp 1460 ... 2026-01-27 18:37:17.322821 port1 in 198.38.101.100.5201 -> 198.38.11.1.3642: udp 1460
2026-01-27 18:37:17.322846 port1 in 198.38.101.100.5201 -> 198.38.11.1.3642: udp 1460
2026-01-27 18:37:17.322913 port1 in 198.38.101.100.5201 -> 198.38.11.1.3642: udp 1460
2026-01-27 18:37:17.323159 port1 in 198.38.101.100.5201 -> 198.38.11.1.21408: psh 3665721898 ack 2487000836
2026-01-27 18:37:17.323202 port1 out 198.38.11.1.21408 -> 198.38.101.100.5201: ack 3665721899
2026-01-27 18:37:17.323360 port1 out 198.38.11.1.21408 -> 198.38.101.100.5201: psh 2487000836 ack 3665721899 So, finally, this feature can be configured on this topology with the following configuration. Although it cannot be run on all the overlays. When there are several overlays on the spoke, the tests are not run on all of them. This seems to be related to the fact that overlays are numbered in this design, which does not allow for establishing all the sessions. Requirements: - The server-side must be configured with the test server enabled. In this example, it has been configured on the Hub.
- Ports used for these tests have to be listening on the server side:
- ctrol-port: 5200 by default, can be customized.
- server-port: 5201 by default, can be customized.
- By default, in the monitoring tests without a license, the servers available to do tests from the client side are detected with 'dynamic-server enable'.
- The interfaces on the server side to carry out the tests will have enabled permission 'speed-test', and they are underlay and overlay, both. In this example, it would be applied on the wan1 interface of the Hub (server) and also on the overlays on the Hub to allow the test (EDGE_ISP1). Also, on spoke, this permission will be added in the overlays where the tests are run. Additionally, the 'BGP on loopback' interface on the server must have also 'speed-test' permission enabled. In this case, loopback 172.30.0.253 on the Hub. This is to enable listening port 5200 on that interface.
- Using BGP on loopback, control plane communication is done over these interfaces; that is why a firewall policy to allow traffic to loopback is required always on the 'server' side.
- Of course, the rest of the configuration included in: Running speed tests from spokes to the hub in dial-up IPsec tunnels must be present.
Configuration: | Configuration on Hub. | Configuration on Spoke. | | config system global ... set speedtest-server enable set speedtestd-ctrl-port 6000 <-- If customized. set speedtestd-server-port 7000 <-- Idem. end config system interface edit "Lo"<<<BGP on loopback set vdom "root" set ip 172.30.0.253 255.255.255.255 set allowaccess ping speed-test set type loopback next edit "port1"<<<for the underlay set ip 198.38.101.100 255.255.255.0 set allowaccess ping https ssh snmp http telnet fgfm radius-acct probe-response fabric speed-test ... next edit "EDGE_ISP1" <-- For the required overlays. set allowaccess ping speed-test ... set interface "port1" next end config firewall policy edit 11 set name "speed-tests CP" set srcintf "OL" set dstintf "Lo" set action accept set srcaddr "all" set dstaddr "all" set schedule "always" set service "UDP_5200-5201" next end | config system speed-test-schedule edit "UL1-H1_ISP1" <-- For the required overlays. set mode TCP set schedules "Test" set dynamic-server enable set update-shaper [local | remote] next edit "UL1-H1_ISP2" set mode TCP set schedules "Test" set dynamic-server enable set update-shaper [local | remote] next ... end config firewall schedule recurring edit "Test" set start 16:24 set end 16:26 set day monday tuesday wednesday thursday friday next end config system interface edit "UL1-H1_ISP1" <-- For the required overlays. set vdom "root" set allowaccess speed-test set type tunnel set egress-shaping-profile "QoS_Out"<<optional set ingress-shaping-profile "QoS_Out"<<optional set outbandwidth [BW] set role wan set interface "port1" next end | | | The configuration of the QoS profile and shaping policy is optional. | Results: One spoke about debugging: diagnose debug application speedtest -1
...
[speedtest(2553)] start uploading test.
[speedtest(2553)] Connecting to host 198.38.101.100, port 5201
[speedtest(2553)] [ 27] local 198.38.11.1 port 16053 connected to 198.38.101.100 port 5201
[speedtest(2553)] [ ID] Interval Transfer Bitrate Total Datagrams
[speedtest(2553)] [ 27] 0.00-1.00 sec 10.3 MBytes 86.1 Mbits/sec 7390
[speedtest(2553)] [ 27] 1.00-2.00 sec 21.7 MBytes 182 Mbits/sec 15580
[speedtest(2553)] [ 27] 2.00-3.02 sec 27.4 MBytes 226 Mbits/sec 19710
[speedtest(2553)] [ 27] 3.02-4.02 sec 28.7 MBytes 240 Mbits/sec 20580
[speedtest(2553)] [ 27] 4.02-5.00 sec 21.9 MBytes 188 Mbits/sec 15740
[speedtest(2553)] [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[speedtest(2553)] [ 27] 0.00-5.00 sec 110 MBytes 184 Mbits/sec 0.000 ms 0/79000 (0%) sender
[speedtest(2553)] [ 27] 0.00-5.00 sec 74.0 MBytes 124 Mbits/sec 0.000 ms 25838/78957 (33%) receiver
[speedtest(2553)] client(sender): bytes_recv=77553740, bytes_sent=115340000, sender_time=5.001, recver_time=5.000
[speedtest(2553)] client(sender): up_speed: 124 Mbits/sec
[speedtest(2553)] speed test Done.
[speedtest(2553)] start downloading test.
[speedtest(2553)] Connecting to host 198.38.101.100, port 5201
[speedtest(2553)] Reverse mode, remote host 198.38.101.100 is sending
[speedtest(2553)] [ 27] local 198.38.11.1 port 3642 connected to 198.38.101.100 port 5201
[speedtest(2553)] [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[speedtest(2553)] [ 27] 0.00-1.00 sec 25.8 MBytes 216 Mbits/sec 0.638 ms 43815/62345 (70%)
[speedtest(2553)] [ 27] 1.00-2.00 sec 36.7 MBytes 308 Mbits/sec 0.003 ms 117340/143693 (82%)
[speedtest(2553)] [ 27] 2.00-3.00 sec 24.6 MBytes 206 Mbits/sec 0.121 ms 45826/63467 (72%)
[speedtest(2553)] [ 27] 3.00-4.00 sec 31.5 MBytes 264 Mbits/sec 0.233 ms 60006/82643 (73%)
[speedtest(2553)] [ 27] 4.00-5.00 sec 23.7 MBytes 199 Mbits/sec 0.055 ms 80405/97436 (83%)
[speedtest(2553)] [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[speedtest(2553)] [ 27] 0.00-5.00 sec 626 MBytes 1.05 Gbits/sec 0.000 ms 0/449640 (0%) sender
[speedtest(2553)] [ 27] 0.00-5.00 sec 142 MBytes 239 Mbits/sec 0.055 ms 347392/449584 (77%) receiver
[speedtest(2553)] client(recver): bytes_recv=149200320, bytes_sent=656474400, sender_time=5.000, recver_time=5.000
[speedtest(2553)] client(recver): down_speed: 239 Mbits/sec
[speedtest(2553)]
[speedtest(2553)] speed test Done.
fcron_speedtest_notify_func()-1277: Speed test pid=2553 done
fcron_speedtest_on_test_finish()-1211: Test 160007 for 'UL1-H1_ISP1' succeed with up=124085, down=238710
fcron_speedtest_apply_dynamic_shaper()-1116: Apply shaping profile 'QoS_Out' with bandwidth 124085 to tunnel UL1-H1_ISP1 of interface UL1-H1_ISP1
fcron_speedtest_save_results()-1144: Write logs to disk: succ=1, fail=0
fcron_speedtest_sync_results()-1172: Sync cached results to secondary devices. Debug commands below: On spoke: diagnose debug application speedtest -1. On hub: diagnose debug application speedtestd -1.
Issues found:
There seems to be a restriction to allow the tests on all the overlays, as the results of several tests have demonstrated. The reason is related to the fact that on BGP on loopback design, the overlays are unnumbered, and there are issues in returning the answers on all the sessions (on all the overlays). Although some workarounds have been tried, this seems to be the reason why documentation does not state this feature for BGP on loopback design. The error for some of the overlays is as follows (EDGE_ISP2_1 in Hub corresponds to one overlay in spoke). Answer to the spoke is attempted repeatedly until the maximum number of attempts is reached: [speedtest(2164)] [sptestd::ctrl(0124):root] EDGE_ISP1(EDGE_ISP1_0, 172.30.0.1) del client uuid=df5399d2-1d23-51f1-9a0c-5c7ef7c1ebdb.
server listening on 5201 (fd=5)
[sptestd::ctrl(0087):root] notify next client: EDGE_ISP2(EDGE_ISP2_1) 172.30.0.1 try=0
[sptestd::ctrl(0087):root] notify next client: EDGE_ISP2(EDGE_ISP2_1) 172.30.0.1 try=1
[sptestd::ctrl(0087):root] notify next client: EDGE_ISP2(EDGE_ISP2_1) 172.30.0.1 try=2
[sptestd::ctrl(0087):root] notify next client: EDGE_ISP2(EDGE_ISP2_1) 172.30.0.1 try=3
[sptestd::ctrl(0087):root] notify next client: EDGE_ISP2(EDGE_ISP2_1) 172.30.0.1 try=4
[sptestd::ctrl(0078):root] client max notify reached.
[sptestd::ctrl(0124):root] EDGE_ISP2(EDGE_ISP2_1, 10.0.0.3) del client uuid=e26a98fa-1d23-51f1-53fc-06b850f58cca.
[speedtest(2164)::serv(0054)] auth result: 3, uuid=e26a98fa-1d23-51f1-53fc-06b850f58cca, peerv4=0.0.0.0
[speedtest(2164)::serv(0192)] test failed: unauthorized test(142) Probably, if IP addressing is used for the overlays, the feature works. | 
