Fortinet black logo

Verifying the performance SLAs on a spoke

Verifying the performance SLAs on a spoke

To verify the performance SLAs on a spoke:
  1. Go to Network > SD-WAN and select the Performance SLAs tab.

  2. Verify that the performance SLA is automatically created for the hub FortiGate. There is a new entry (oaas_overlay_hub).

    • The performance SLAs to the primary and secondary hubs are denoted by oaas_overlay1 and oaas_overlay2, respectively.

    • The performance SLA to the spoke is denoted by oaas_overlay2_0.

Once a shortcut tunnel is established, it is also monitored using the performance SLA. If the performance SLA of the shortcut tunnel exceeds the specified thresholds during operation, then the shortcut tunnel will be removed as the best route learned using BGP in the routing table. Therefore, traffic for the destination spoke will be forwarded by the source spoke through the hub, which is not ideal.

This can be observed from get router info routing-table all:

# get router info routing-table all
…
B       10.1.1.0/24 [200/0] via 10.200.0.57 tag 180879361 (recursive via oaas_overlay2_0 tunnel 172.16.151.95), 00:00:05
                                                          (recursive via oaas_overlay1 tunnel 38.21.192.175), 00:00:05, [1/0]
                    [200/0] via 10.200.0.57 tag 180879363 (recursive via oaas_overlay2_0 tunnel 172.16.151.95), 00:00:05, [1/0]
…

If the oaas_overlay2_0 shortcut tunnel on the source spoke does not meet the performance SLA, the routes through oaas_overlay2_0 will be removed, and then the oaas_overlay1 tunnel to the hub becomes the best path to forward traffic. In that case, traffic will be forwarded to the hub on the way to the destination spoke.

Verifying the performance SLAs on a spoke

To verify the performance SLAs on a spoke:
  1. Go to Network > SD-WAN and select the Performance SLAs tab.

  2. Verify that the performance SLA is automatically created for the hub FortiGate. There is a new entry (oaas_overlay_hub).

    • The performance SLAs to the primary and secondary hubs are denoted by oaas_overlay1 and oaas_overlay2, respectively.

    • The performance SLA to the spoke is denoted by oaas_overlay2_0.

Once a shortcut tunnel is established, it is also monitored using the performance SLA. If the performance SLA of the shortcut tunnel exceeds the specified thresholds during operation, then the shortcut tunnel will be removed as the best route learned using BGP in the routing table. Therefore, traffic for the destination spoke will be forwarded by the source spoke through the hub, which is not ideal.

This can be observed from get router info routing-table all:

# get router info routing-table all
…
B       10.1.1.0/24 [200/0] via 10.200.0.57 tag 180879361 (recursive via oaas_overlay2_0 tunnel 172.16.151.95), 00:00:05
                                                          (recursive via oaas_overlay1 tunnel 38.21.192.175), 00:00:05, [1/0]
                    [200/0] via 10.200.0.57 tag 180879363 (recursive via oaas_overlay2_0 tunnel 172.16.151.95), 00:00:05, [1/0]
…

If the oaas_overlay2_0 shortcut tunnel on the source spoke does not meet the performance SLA, the routes through oaas_overlay2_0 will be removed, and then the oaas_overlay1 tunnel to the hub becomes the best path to forward traffic. In that case, traffic will be forwarded to the hub on the way to the destination spoke.