Throughput of bidirectional TR transmission

For one-way TR transmission, although either download or upload bandwidth of tunnels is consumed by the transferred data packets, bandwidth (in the opposite direction) is available to get relative TCP control packets responded in acceptable latency and correct order. Both the download and upload bandwidth will be consumed if the tunnels are loaded with bidirectional connections. Respondent TCP control packets of a connection and data packets of another connection will scramble for limited bandwidth. In the meantime, distributing TCP control packets of a connection over tunnels must bring higher latency and out-of-order delivery and result in poor transmission performance. To guarantee expected throughput for bidirectional TR transmission, FortiWAN Tunnel Routing fixes TCP control packets (packets without data payloads) of all connections running on a TR group to a single tunnel (rather than distributing them over tunnels), which will significantly reduce latency and out-of-order delivery. This specific tunnel is not reserved for only TCP control packets, parts of data packets of connections will also be assigned to this tunnel according to the specified balancing algorithm. Therefore, this specific tunnel is supposed to be the most stable (largest bandwidth, best quality) one in the tunnel (refer to the above description for how to evaluate a tunnel). This mechanism requires no extra configurations, but needs posit the tunnels on the configuration GUI in a appropriate ordering , see Tunnel Routing – Setting.

Persistent Route in Tunnel Routing

As the above description, Tunnel Routing could hardly 100% aggregate bandwidth of multiple tunnels for TCP connections. TCP is intrinsically such sensitive to factors, such as latency, packet out-of-order delivery, TCP window size, quality of the links and etc., so that there will always be a bottleneck to the transmission performance, as long as packets of each connection are distributed over multiple tunnels. However, on the other hand, higher bandwidth usage (almost 100%) of multiple tunnels could be achieved if Tunnel Routing just persistently transfers packets of each connection via a single tunnel rather than distributing them over multiple tunnels. Like the cooperation of Persistent Routing and Auto Routing (see Outbound Load Balancing and Failover (Auto Routing) and Persistent Routing), Tunnel Routing supposes the Persistent Routing as well. Although a persistently-routed TR connection will be bounded in performance by the maximum throughput of the tunnel that TR fixes it to (conversely, a packet-distributed TR connection can use aggregated bandwidth of tunnels, even if it is about a maximum of 70% aggregation), in real practice, Tunnel Routing will not serve only one connection at a time; there will always be various connections existing concurrently between two sites and tunnels are full of their traffic. In that case, each connection need compete with others for available bandwidth and it is hard to tell whether a packet-distributed connection or a persistently-routed connection runs in better throughput, but it certainly gives higher usage of overall bandwidth if all the connection in tunnels are persistently-routed.

Here is the comparison between packet-distributed TR connection and persistently-routed TR connection.

Packet-distributed TR connection

l Bandwidth of multiple tunnels are aggregated for a connection. l There is no impact to a connection when single tunnel fails. l A connection is sensitive to TCP parameters of all the participating tunnels. l A connection can hardly use more that 70% aggregated bandwidth. l The overall connections running on the tunnels can hardly use more that 70% aggregated bandwidth.

Persistently-routed TR connection

• Bandwidth aggregation is not available for a connection. l Single tunnel failure impacts the connection. l Only TCP parameters of the specified tunnel effects the connection. l Performance of a connection is bounded by throughput of the specified tunnel.
• The overall connections running on the tunnels can use almost 100% aggregated bandwidth (number of connections must be larger than number of participating tunnels).

You might have various non-critical traffic and critical applications between sites in the Tunnel Routing (intranet) network. Packet-distributed Tunnel Routing is suggested for critical application requiring higher level of loadbalancing and fault-tolerance, such as remote database backup, while persistently-routing Tunnel Routing might be more suitable to non-critical traffic for better overall TR transmission performance. Tunnel Routing performance is a complex topic, so that you need to take a deliberation on this before configuration. See section Persistent Rules in How to set up routing rules for Tunnel Routing for configuring it.

Default rule

If your TR network deployment requires more than 100 TR routing rules, replacing the TR routing rules with TR default rules will be suggested for better performance (see How to set up routing rules for Tunnel Routing).

Bandwidth Management

Tunnel Routing is designed to be transparent to FortiWAN’s Bandwidth Management (See “Bandwidth Management”). The way to allocate or limit bandwidth to traffic of Tunnel Routing is to drill it down to the original packets, control the traffic by individual service, source or destination. In other words, the traffic of individual service transferred through Tunnel Routing can be controlled. Guaranteeing proper bandwidth to individual traffic helps for the performance of Tunnel Routing transmission. Packets encapsulated by Tunnel Routing becomes invisible to Bandwidth Management; controlling the overall Tunnel Routing traffic by service GRE will go to failure.

Scale

For large-scale Tunnel Routing network deployment, FortiWAN supports up to 100 tunnel groups for FWN-200B, 400 tunnel groups for FWN-1000B and 1000 tunnel groups for FWN-3000B. All of the three models have a default maximum total allowed enable amount of 2500 GRE tunnels (total amount of enabled GRE tunnels of all the tunnel groups).

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Tunnel Routing service, see “Log”, “Statistics: Tunnel Status”, “Statistics: Tunnel Traffic”, “Report: TR Status” and “Report: TR Reliability”.

See also

Tunnel Routing

Tunnel Routing – Setting

How to set up routing rules for Tunnel Routing

Tunnel Routing – Benchmark

Scenarios