OSPF tuning

OSPF default parameters run well in common scenarios, but we need to do some tuning to match our specific situations. Especially using slow WAN links (LTE or other unreliable provider links) in active/standby or active/active mode, we need to tune some parameters to suit our needs.

Using below VPN gateway & client example, we will explain more details for each parameter. 

VPN gateway config

VPN Client config

Note "tap ospf xxx" config under "security sslvpn...." config essentially auto generates respective "ip ospf xxx" config for its tap interface. For example,

After tunnel is established, a set of new config will be auto created as below

So both are referring to the same config, just syntax difference under different context. In this document, we may inter-changeably use "tap ospf xx" and "ip ospf xx".

tap ospf priority xx

For each VPN instance, It's very important to apply "tap ospf priority 255" at sslvpn-server end, and config "tap ospf priority 0" at sslvpn-client end. This makes sure that the Server/Gateway side always has the highest priority and remain as DR, so that routes can be propagated from the gateway hub to remote clients.

tap ospf cost xx

When you have multiple WAN links (tunnels), this parameter is used to manually manipulate which instance tunnel is active (lower cost) and which is standby (higher cost). NOTE, both server and client must set the same value for the same VPN instance. If you leave default (10), both tunnels will have same cost and traffic will be load balance across tunnels.

tap ospf hello-interval 20

tap ospf dead-interval 80

These two parameters are often used together. It's very important to note that both VPN gateway/server and remote client must set the same values for each instance. If the tunnel runs across slow links, it's recommended increase default value to something higher (default hello-interval is 10, dead-interval is 40), so that the neighboring is more tolerant to delay and less flapping.

tap ospf transmit-delay 10

The transmit delay timer increments the age of LSAs in update packets to accommodate transmission and propagation delays for the interface. For slow links, It's recommended to increase to something higher. default (1 sec) . Do the same for both gateway and client, for the same instance.

tap ospf mtu-ignore

Sometimes you may experience OSPF neighbors are forever stuck in EXSTART or EXCHANGE state. The root cause is likely due to MTU size mismatch on the Server & client end. Sometimes could due to each end uses different WAN connections, or simply could due to firmware differences. (NOTE, in earlier firmware, the SSLVPN tunnel default MTU size is 1500; in newer firmware, the SSLVPN tunnel default MTU size increased to 12000 (this helps to improve tunnel throughput). If you have boxes running different firmware, you may experience MTU size mis-match (use "show interface" command to check MTU size for tap interface, on both gateway and client boxes). You can either manually change mtu size by setting "tap mtu 1500", or use "tap ospf mtu-ignore" to ignore the differences.