Optimum Route Detection
FortiWAN’s Optimum Route is a particular load balancing algorithm which determines the best WAN link for Auto
Routing and Multihoming by involving real Internet conditions in calculation, while the other algorithms, such as By Round-Robin, By Connection and By Upstream/Downstream/Total Traffic, only focus on the loading between the FortiWAN device and ISP’s gateways. Optimum Route is used mainly to avoid the inefficient transmission due to bad peering between ISPs. Peering between two ISPs is an interconnection of administratively separated Internet networks (belonging to the two ISPs individually) for the purpose of exchanging traffic between the users in each network. It allows the two ISP to directly hand off the traffic between each other’s customers, which might be the most efficient way to communicate between two networks if it is settlement-free. However, two situations might cause the transmission between two ISP networks inefficient; l If there is no agreement by the two ISP networks to peer, the transit service, which is a method to carry that traffic across one or more third-party networks (a few exchange points), will be required.
- An ISP restricts the bandwidth for peering with another ISP on the purpose of competition in business. The peering point thus becomes a bottleneck and might make the transmission extremely slow between each other’s customers.
Although the other balancing algorithms determine a good WAN link among multiple WAN links (multiple ISP networks) for inbound and outbound traffic, they are not aware of the real situations between those ISPs. For example, two WAN links of a FortiWAN device are connected to ISP-A and ISP-B networks and the peering between each other is bad. Those non-optimum-route balancing algorithms might determine ISP-B WAN link for Auto Routing to transfer the traffic which is destined to a server located in ISP-A network (see Auto Routing). If the bad peering between ISP-A and ISP-B is the only exchange point, which is the bottleneck, for delivering the traffic, the transmission will become slow. Conversely, those balancing algorithms may also determine the IP of ISP-B WAN link for Multihoming (see Multihoming) to answer DNS queries coming from ISP-A network. Then the users in ISP-A network suffer the bad peering when accessing services on FortiWAN through ISP-B network.
Algorithm Optimum Route is just the opposite of those algorithms. It determines the optimum WAN link by going deep into the real Internet conditions in two modes: static IP table and dynamic detect.
- Static IP table: A static IP table is a set of the IP addresses of an ISP network. Optimum Route evaluates the destination IP of out-going sessions against the IP tables for Auto Routing, and evaluates the source IP of DNS queries against the IP tables for Multihoming. If the evaluated IP matches the IP table of an ISP, which implies the ISP network that the evaluated IP belongs to is recognized, this ISP WAN link will be the optimum routing. Conceptually, it directly asks traffic being delivered directly through a WAN link connected to the ISP network that traffic source or destination belong to, so that traffic will not suffer a peering. This can be also implemented by specifying the source or destination filter with IP groups (See “IP Grouping”) in Multihoming or Auto Routing rules.
- Dynamic detect: It dynamically evaluates WAN links according to the detected round-trip time (RTT) and the bandwidth loading. Bad peering brings bad RTT value.
The following configurations define how Optimum Route detect to determine an optimum WAN link. To use the
Optimum Route algorithm in Auto Routing and Multihoming, it requires specifying the algorithm “By Optimum Route” for a Auto Routing policy and A/AAAA Record policy, and applying the policy to corresponding filter rules and A/AAAA records. Without this, Optimum Route would never work even if the detection is configured. FortiWAN provides DNS Proxy to cooperate with Optimum Route to resolve an advanced issue caused by bad peering (See “DNS Proxy”).
Optimum Route Policy
| Static IP Table | Uses static IP table only. |
| Dynamic Detect | Uses dynamic detection only. |
| Static, Dynamic | Uses static detection first, then switches over to dynamic detection if static detection fails. [Static, Dynamic] is the default detection method. |
| Dynamic, Static | Uses dynamic detection first, then switches over to static detection if dynamic detection fails. |
Static IP-ISP Table
Enables to match the IP address entries in the table to work out the optimum route. Administrators can add, delete or inquire the desirable IP entry in the table.
The static IP-ISP tables are the reference for Optimum Route to recognize the ISP network that the source or destination IP of traffic belongs to and so that point the traffic to corresponding WAN link, which is the optimum routing. A static IP-ISP table contains the IP subnets of an ISP network. You have to maintain these IP subnets in a text file for creating an IP-ISP table. Each line of the text file indicates a IP subnet in format Network IP/Prefix, for example:
3.0.0.0/8
211.1.0.0/16
Note that it is strongly suggested that an IP file contains the IP subnets of only ISP, or Optimum Route might not run as expected. Please prepare the IP files for the IP-ISP tables. Another component of static IP-ISP table is the
WAN parameter, which indicates the FortiWAN’s WAN links connecting to the ISP’s network. Once traffic
matches the IP subnets of an IP-ISP table, Optimum Route determines a WAN link from the candidates. It is not such strictly limited that an ISP’s IP subnets can only be recorded in one IP-ISP record (just make sure an IP-ISP table contains only one ISP). The IP subnets of an ISP can be separated into multiple IP-ISP tables, just remember Optimum Route evaluates traffic against the tables top down by first match, and it picks up one of the corresponding WAN links if a table is matched.
| Table Name | Name for the IP-ISP Table, such as an ISP’s name. | ||
| Setting | Set the IP subnets of an ISP to the table. | ||
| Upload Upload the IP file of a ISP to save the ISP’s IP subnets to the static IPISP table. Click “Browse” to locate the IP file and click “Upload” to upload the file. You are required to upload an IP file (click “Upload”) first, then apply (click “Apply”) the settings of the IP-ISP table. Note that an IP table file is necessary to create a static IP-ISP table.
After saving the IP subnets to the table, you might continue maintaining (add or remove) the IP subnets of the ISP. You can make it by editing the subnets in the following field Rule Setting or manually editing the IP file and re-upload it to the table. IP file re-uploading overwrites the original IP subnets of the table. |
|||
| Rule Setting | After uploading the IP file to the table, you can manually edit it by adding/removing subnets to/from the IP table if necessary. Without uploading an IP file to the table first, it is ineffective to add/remove IP subnets to/from the table. | ||
| Subnet Address | Specify a subnet address to add/remove to/from the table. The acceptable format is [network address/netmask] or [network address/prefix], such as 202.99.0.0/255.255.255.0 or 202.99.0.0/24. A single IP or an unusual subnet mask like “/255.255.255.255” or “/32” is unacceptable. | ||
| Action | Select the action for the specified subnet.
Add to: Add the specified subnet to the static IPISP table. Remove from: Remove the specified subnet from the static IP-ISP table. |
||
| Parameter | Select the WAN links that are connected to the ISP network that this IP-ISP table indicates. Check the field of WAN link to select it. Multiple selection is allowed if more than one WAN link is connected to the same ISP network. Be ensure that the selected WAN links are exactly connected to the ISP network that the table indicates, or the Optimum Route might not run as excepted. | ||
| IP Query | Inquire if a single IP address is in the static IP table. | ||
When the source or destination IP of a packet matches an static IP-ISP table, Optimum Route determines a WAN link from the intersections of the WAN parameters here and the corresponding WAN parameters of a Auto Routing policy or Multihoming A/AAAA record policy, according to the traffic loading on the WAN ports. For example:
Auto Routing policy: Label=By_OR, Algorithm=By Optimum Route, Parameter=1,2,3 (checked)
The matched IP-ISP table: Table Name=ISP_A, Parameter=2,3,4 (checked)
Traffic matches a Auto Routing filter rule is processed by Auto Routing according to the corresponding policy “By_ OR”. Optimum Rout is set to detect network by static IP-ISP table. Packet destination IP of the traffic matches the ISP’s network of IP-ISP table “ISP_A”, which WAN links 2, 3 and 4 are connected to the ISP network. Optimum Route determines a WAN link for Auto Routing from WAN link 2 and WAN link3, which are the intersections of WAN links 1, 2, 3 (WAN parameters set in the AR policy) and WAN links 2, 3, 4 (WAN parameters set in the IP-ISP table). If traffic loading on WAN port 2 is currently heavier than WAN port 3, WAN link 3 will be the optimum link that Optimum Route decides for Auto Routing. The traffic will then be transferred through WAN link 3 by Auto Routing. For Multihoming with algorithm By Optimum Rout, the process is similar.
Here are the situations cause Optimum Route by IP-ISP table detection returning nothing to Auto Routing and Multihoming:
- Optimum Route returns nothing when the evaluated packet source and destination IP does not match any of the IPISP tables. This might because of incomplete collection of IP subnets of ISP networks. You can make the IP-ISP tables more complete by continuing IP subnets collecting and adding them to the tables. The more complete the IP subnets are, the better effect Optimum Route brings.
- Even if traffic matches an IP-ISP table, Optimum Route returns nothing when there is no intersection of Optimum Route’s WAN parameters and Auto Routing (or Multihoming) policy’s WAN parameters. Please make sure at least one intersected WAN link between the policies.
The traffic will be processes by Auto Routing according to the specified fail-over policy (see Auto Routing), if Optimum Route returns nothing to Auto Routing for the traffic. Multihoming will answer the IP address defined to the first WAN link in the A/AAAA record policy (see Multihoming), if Optimum Route returns nothing to Multihoming for the query.
Dynamic Detect
Optimum Route’s dynamic detection detects the round-trip time (RTT) of traffic targets and involves it to a dynamic calculation to determine the optimum WAN link for Auto Routing and Multihoming. Optimum Route spreads detection packets to a target through all the enabled WAN links to collect the transmission latency between the FortiWAN device and the target via each WAN link (ISP). In Optimum Route, this RTT will also represent the latency for data transmission through each WAN link between the FortiWAN device and the class C that the detection target belongs to. Fort example, if Optimum Route detects 20 ms, 30 ms and 40 ms RTTs between FortiWAN and a target 211.21.1.100 through WAN link 1, 2 and 3, a reference table as follow will be maintained and cached for a wile:
Subnet=211.21.1.0/24, WAN1=20ms, WAN2=30ms, WAN3=40ms
During the cache period, Optimum Route uses the values directly to calculate the optimum WAN link for any subsequent traffic that the target belongs to subnet 211.21.1.0/24. As for the target we are talking about, Optimum Route takes the destination IPs of out-going session packets as the targets if they matches the relevant Auto Routing policies, and takes the source IPs of DNS queries as the targets if they matches the relevant Multihoming A/AAAA record policies.
To determine an optimum WAN link, Optimum Route evaluates on availability of the candidates by calculating the weight of each WAN link. The calculation of weight involves the detected RTT and current traffic loading, which are combined in specified ratio. It seems making sense that the less the RTT is the optimum the WAN link is, but practically it is not necessarily that data transmission to a target through a WAN link with less RTT but serious traffic congestion on the WAN port is better than through a WAN link with higher RTT but the WAN port is in full-availability.
To enable dynamic detection for Optimum Route, it requires to have the following settings configured. It contains three parts:
l The protocol and procedure used for detecting RTT. l The time period for caching detected RTT. l The ratio of RTT and traffic loading for availability evaluation.
| Detection Protocol | ICMP and TCP are the protocols used to detect the RTT (Default: ICMP). ICMP (ping) or TCP (TCP connect request) packets are sent to a target through each of the enabled WAN links. So that system gets RTTs from the responses. Here are the options for the detection protocol:
ICMP: Using ICMP for detections. TCP: Using TCP for detections ICMP, TCP: Using ICMP for detections first. System will try TCP detection if the ICMP detections are declared failed. TCP, ICMP: Using TCP for detections first. System will try ICMP detection if the TCP detections are declared failed. |
| Detection Period, in Seconds | The time interval between retries if there is no response received for current detection. (Default: 3 seconds). |
| Number of Retries | The times that system will retry if detections continue receiving no responses (Default: 3 retries). Retry will stop as long as a response is received, or system will declare the RTT detection is failed if all the retries receive no responses. |
| Cache Aging Period, in Minutes | The time period to cache the detected results (Default: 2880mins, ie. 2days). After the cache is cleaned, system will re-trigger detections for the same request. |
| Weight of Round Trip Time : Weight of Load | A parameter used to calculate the optimum route. It shows how much round trip time (RTT) and link load account for in calculating the optimum route. Note: The smaller the field value is, the less it accounts for in optimum route calculation. |