Fortinet white logo
Fortinet white logo

Administration Guide

Hub and spoke speed tests

Hub and spoke speed tests

In an SD-WAN hub and spoke topology, connections between sites are typically made through VPN overlays. The hub usually acts as the VPN gateway with spokes connecting as dial-up VPN clients. In order to estimate the speed of the connection to each spoke, speed tests can be performed between the hub and each spoke. The results of the speed test can be used for egress traffic shaping on the VPN overlay tunnel.

A speed test server can be enabled on the hub or spoke with custom speed-test listening ports. The test measures the speeds of the link to each spoke so that QoS can be applied on the hub to the egress traffic shaping profile assigned to the IPsec overlay tunnel interface and the respective tunnel. An egress-shaping profile can be applied to local, remote, or both local and remote IPsec tunnels or no IPsec tunnels. Tests can be in upload or download direction and support both TCP and UDP protocols.

Speed test results are cached for future use. When speed tests are initiated from the hub, the results are cached on the hub. When speed tests are initiated from the spoke, the results are cached on the spoke, but sent to the hub.

When a speed-test server is enabled on a hub or spoke, two speed test daemons are started and listen on different ports for different purposes:

  • The controller speed test daemon listens on the IPsec overlay interfaces to assign an access token to each incoming speed test for authentication.

  • The speed test daemon listens on the IPsec underlay interfaces to handle the speed tests.

Each incoming speed test request must present the obtained access token to prevent random, unauthorized requests. Otherwise, the connection is closed immediately. As such, speed test access must be enabled on both the underlay and the IPsec overlay tunnel interfaces.

config system interface
    edit <interface>
        set allowaccess speed-test [other access] ...
    next
end
Note

If the IPsec tunnel has a configured exchange-ip, speed test access must also be configured on the associated interface, such as the loopback interface.

The speed test client can be a hub or a spoke and must have system speed-test-schedule configured and the dynamic-server setting enabled. The speed-test schedule initiates the test.

On the speed test client, specify whether and how to apply the test results in a shaping profile. The shaping profile must be configured in the phase1 interface before it can be used with a speed test.

config system speed-test-schedule
    edit <interface>
        set server-port <integer>
        set ctrl-port <integer>
        set update-shaper {disable | local | remote | both}
    next
end

set server-port <integer>

Specify the port number for the speed-test server used for speed tests (1 - 65535, default = 5201).

set ctrl-port <integer>

Specify the port number for the controller on the speed-test server used for authentication (1 - 65535, default = 5200).

set update-shaper {disable | local | remote | both}

Set the egress shaper to use the speed test results:

  • disable: Disable updating the egress shaper (default).

  • local: Update the speed-test client egress shaper.

  • remote: Update the speed-test server egress shaper.

  • both: Update both the local and remote egress shapers.

CLI commands

Enable the speed-test server:
config system global
    set speedtest-server {enable | disable}
    set speedtestd-server-port <integer>
    set speedtestd-ctrl-port <integer>
end

speedtest-server {enable | disable}

Enable/disable the speed test server on the hub or spoke (default = disable).This enables iPerf in server mode, which listens on the default iPerf TCP port 5201.

set speedtestd-server-port <integer>

Specify a custom port number (1024 - 65535, default = 5201) for the speed test daemon. The port is used to perform the speed test.

set speedtestd-ctrl-port <integer>

Specify a custom port number (1024 - 65535. default = 5200) for the controller speed test daemon. The port is used to assign access tokens for authentication prior to performing the speed test.

Enable the speed test client:
config system speed-test-schedule
     edit <interface>
        set dynamic-server {enable | disable}
        set ctrl-port <integer>
        set server-port <integer>
        set update-shaper {disable | local | remote | both} 
     next
 end

<interface>

The dial-up IPsec tunnel interface on the speed test client. The speed test client can be the hub or the spokes.

dynamic-server {enable | disable}

Enable/disable the dynamic speed test server (default = disable).

Ctrl-port <integer>

Specify the port number for the controller on the speed-test server used for authentication (1 - 65535, default = 5200).

Server-port <integer>

Specify the port number for the speed-test server used for speed tests (1 - 65535, default = 5201).

Update-shaper {disable | local | remote | both}

Set the egress shaper to use the speed test results:

  • disable: Disable updating the egress shaper (default).

  • local: Update the speed-test client egress shaper.

  • remote: Update the speed-test server egress shaper.

  • both: Update both the local and remote egress shapers.

Note

To limit the maximum bandwidth used in the speed test, enable set update-inbandwidth and set update-outbandwidth. See Scheduled interface speed test for more information.

Enable speed test access on both the underlay and the IPsec overlay tunnel interfaces on the speed test server:
config system interface
    edit <interface>
        set allowaccess speed-test [other access] ...
    next
end

<interface>

The dial-up IPsec tunnel interface on the speed test server.

set allowaccess {speed-test | [other access]}

Enable speed-test access on the underlay and IPsec overlay interfaces.

Allow an SD-WAN member on the spoke to switch routes when on speed test from the hub to spokes:
config system sdwan
    set speedtest-bypass-routing {enable | disable}
    config neighbor
        edit <bgp neighbor>
            set mode speedtest
        next
    end
end

speedtest-bypass-routing {enable | disable}

Enable/disable bypass routing when doing a speed test on an SD-WAN member (default = disable).

set mode speedtest

Use the speed test to select the neighbor.

Manually run uploading speed test on the physical interfaces of each tunnel of a dial-up IPsec interface:
execute speed-test-dynamic <interface> <tunnel_name> <'y'/'n'> <max-out> <min-out>

<interface>

IPsec phase1 interface name.

<tunnel_name>

The tunnel name, or all for all tunnels.

<'y'/'n'>

Apply the result to the tunnels' shaper or not.

<max-out>

The maximum speed used in a speed test, in kbps.

<min-out>

The minimum speed used in a speed test, in kbps.

Manually run a non-blocking uploading speed test:
diagnose netlink interface speed-test-tunnel <interface> <tunnel_name>
Debug and test commands:

diagnose debug application speedtest <int>

Enable debug of the speed test module in the forticron daemon.

diagnose debug application speedtestd <int>

Enable debug of the speed test server daemon.

diagnose test application forticron 9

List the scheduled speed tests.

diagnose test application forticron 10

Show the cached speed test results.

diagnose test application forticron 11

Write the cached speed test results to disk.

diagnose test application forticron 12

Load the speed test results from disk.

diagnose test application forticron 99

Cancel all pending speed tests.

Hub and spoke speed tests

Hub and spoke speed tests

In an SD-WAN hub and spoke topology, connections between sites are typically made through VPN overlays. The hub usually acts as the VPN gateway with spokes connecting as dial-up VPN clients. In order to estimate the speed of the connection to each spoke, speed tests can be performed between the hub and each spoke. The results of the speed test can be used for egress traffic shaping on the VPN overlay tunnel.

A speed test server can be enabled on the hub or spoke with custom speed-test listening ports. The test measures the speeds of the link to each spoke so that QoS can be applied on the hub to the egress traffic shaping profile assigned to the IPsec overlay tunnel interface and the respective tunnel. An egress-shaping profile can be applied to local, remote, or both local and remote IPsec tunnels or no IPsec tunnels. Tests can be in upload or download direction and support both TCP and UDP protocols.

Speed test results are cached for future use. When speed tests are initiated from the hub, the results are cached on the hub. When speed tests are initiated from the spoke, the results are cached on the spoke, but sent to the hub.

When a speed-test server is enabled on a hub or spoke, two speed test daemons are started and listen on different ports for different purposes:

  • The controller speed test daemon listens on the IPsec overlay interfaces to assign an access token to each incoming speed test for authentication.

  • The speed test daemon listens on the IPsec underlay interfaces to handle the speed tests.

Each incoming speed test request must present the obtained access token to prevent random, unauthorized requests. Otherwise, the connection is closed immediately. As such, speed test access must be enabled on both the underlay and the IPsec overlay tunnel interfaces.

config system interface
    edit <interface>
        set allowaccess speed-test [other access] ...
    next
end
Note

If the IPsec tunnel has a configured exchange-ip, speed test access must also be configured on the associated interface, such as the loopback interface.

The speed test client can be a hub or a spoke and must have system speed-test-schedule configured and the dynamic-server setting enabled. The speed-test schedule initiates the test.

On the speed test client, specify whether and how to apply the test results in a shaping profile. The shaping profile must be configured in the phase1 interface before it can be used with a speed test.

config system speed-test-schedule
    edit <interface>
        set server-port <integer>
        set ctrl-port <integer>
        set update-shaper {disable | local | remote | both}
    next
end

set server-port <integer>

Specify the port number for the speed-test server used for speed tests (1 - 65535, default = 5201).

set ctrl-port <integer>

Specify the port number for the controller on the speed-test server used for authentication (1 - 65535, default = 5200).

set update-shaper {disable | local | remote | both}

Set the egress shaper to use the speed test results:

  • disable: Disable updating the egress shaper (default).

  • local: Update the speed-test client egress shaper.

  • remote: Update the speed-test server egress shaper.

  • both: Update both the local and remote egress shapers.

CLI commands

Enable the speed-test server:
config system global
    set speedtest-server {enable | disable}
    set speedtestd-server-port <integer>
    set speedtestd-ctrl-port <integer>
end

speedtest-server {enable | disable}

Enable/disable the speed test server on the hub or spoke (default = disable).This enables iPerf in server mode, which listens on the default iPerf TCP port 5201.

set speedtestd-server-port <integer>

Specify a custom port number (1024 - 65535, default = 5201) for the speed test daemon. The port is used to perform the speed test.

set speedtestd-ctrl-port <integer>

Specify a custom port number (1024 - 65535. default = 5200) for the controller speed test daemon. The port is used to assign access tokens for authentication prior to performing the speed test.

Enable the speed test client:
config system speed-test-schedule
     edit <interface>
        set dynamic-server {enable | disable}
        set ctrl-port <integer>
        set server-port <integer>
        set update-shaper {disable | local | remote | both} 
     next
 end

<interface>

The dial-up IPsec tunnel interface on the speed test client. The speed test client can be the hub or the spokes.

dynamic-server {enable | disable}

Enable/disable the dynamic speed test server (default = disable).

Ctrl-port <integer>

Specify the port number for the controller on the speed-test server used for authentication (1 - 65535, default = 5200).

Server-port <integer>

Specify the port number for the speed-test server used for speed tests (1 - 65535, default = 5201).

Update-shaper {disable | local | remote | both}

Set the egress shaper to use the speed test results:

  • disable: Disable updating the egress shaper (default).

  • local: Update the speed-test client egress shaper.

  • remote: Update the speed-test server egress shaper.

  • both: Update both the local and remote egress shapers.

Note

To limit the maximum bandwidth used in the speed test, enable set update-inbandwidth and set update-outbandwidth. See Scheduled interface speed test for more information.

Enable speed test access on both the underlay and the IPsec overlay tunnel interfaces on the speed test server:
config system interface
    edit <interface>
        set allowaccess speed-test [other access] ...
    next
end

<interface>

The dial-up IPsec tunnel interface on the speed test server.

set allowaccess {speed-test | [other access]}

Enable speed-test access on the underlay and IPsec overlay interfaces.

Allow an SD-WAN member on the spoke to switch routes when on speed test from the hub to spokes:
config system sdwan
    set speedtest-bypass-routing {enable | disable}
    config neighbor
        edit <bgp neighbor>
            set mode speedtest
        next
    end
end

speedtest-bypass-routing {enable | disable}

Enable/disable bypass routing when doing a speed test on an SD-WAN member (default = disable).

set mode speedtest

Use the speed test to select the neighbor.

Manually run uploading speed test on the physical interfaces of each tunnel of a dial-up IPsec interface:
execute speed-test-dynamic <interface> <tunnel_name> <'y'/'n'> <max-out> <min-out>

<interface>

IPsec phase1 interface name.

<tunnel_name>

The tunnel name, or all for all tunnels.

<'y'/'n'>

Apply the result to the tunnels' shaper or not.

<max-out>

The maximum speed used in a speed test, in kbps.

<min-out>

The minimum speed used in a speed test, in kbps.

Manually run a non-blocking uploading speed test:
diagnose netlink interface speed-test-tunnel <interface> <tunnel_name>
Debug and test commands:

diagnose debug application speedtest <int>

Enable debug of the speed test module in the forticron daemon.

diagnose debug application speedtestd <int>

Enable debug of the speed test server daemon.

diagnose test application forticron 9

List the scheduled speed tests.

diagnose test application forticron 10

Show the cached speed test results.

diagnose test application forticron 11

Write the cached speed test results to disk.

diagnose test application forticron 12

Load the speed test results from disk.

diagnose test application forticron 99

Cancel all pending speed tests.