Defining Traffic Path Rules
Balancing traffic using traffic path rules
Traffic path rules (or path selection) is a granular set of rules that balance traffic over multiple WANs: internet, RouteVPN, and MPLS. For example, in a hybrid network environment, you might want more important data like voice to traverse the MPLS private network, Salesforce traffic from your sales team to be sent directly to the internet, and all business traffic to be sent over the secure VPN. All paths are monitored by ICMP pings. If a path is down, the traffic is switched to the remaining paths.
Traffic path rules select WAN paths
Traffic path rules:
•overwrite path preference for certain types of traffic.
•overwrite QoS priorities.
•can select the best path based on path preference and path quality metrics (that is, latency, jitter, and loss).
SteelConnect performs application detection on the first packet seen by the gateway. The gateway searches for the hostname from the local DNS cache and then it sends the request to the application controller server. If there isn’t a DNS entry in the cache, then the IP address is used. The system checks every third packet to make sure the hostname hasn’t changed. If the hostname changes, it is reclassified and SteelConnect reapplies all firewall rules again.
Traffic path rules are applied on the gateway side of the network where the traffic was initiated. This means that when a client creates a TCP connection to a remote server, traffic path rules only apply on the client gateway and not on the server gateway a second time.
The return path is expected to use the same path as the gateway that initiated the connection. Because the remote site keeps track of where the traffic entered the gateway, it maintains path consistency based on the interface that initiated the connection.
Traffic path rules take effect on different WANs, not uplinks. For example, it isn’t possible to define traffic path rules for two internet connections because they are both on the same WAN.
Currently, all traffic rules fall through; that is, if you have an MPLS rule and it isn’t reachable, then the traffic flow falls through to the next rule until the traffic is matched. If no rule is found, then the traffic reverts to the default rule.
When you create traffic path rules, they overwrite the organization internet breakout and WAN usage preferences that you set when you created an organization.
SteelConnect uses this process to make traffic balancing decisions between WANs:
1. SteelConnect decides whether the traffic is going to the internet or staying in the corporate network.
2. To steer traffic flows between WANs, SteelConnect selects which WAN (for example, MPLS, RouteVPN, or Internet) the traffic will use according to the Path Preference that you set from the first to last.
3. If a Path Quality profile is defined for a rule, path quality metrics are applied to the traffic flow. For example, if your Path Quality profile has Latency Sensitive metrics applied, the system uses latency, jitter, and loss metrics to determine the best path.
If a Path Preference is specified (for example, RouteVPN and MPLS), the gateway selects from the preference order specified. If a Path Quality profile is also specified (for example, Latency Sensitive or Interactive Metrics) then the gateway chooses the best path based on measured data metrics from the paths defined in Path Preferences, except for SDI-5030 gateways, which will choose from all available paths regardless of Path Preference. If all paths are equal according to the selected Path Quality profile metrics, then path selection will fall back to Path Preference.
4. When there aren’t any traffic path rules defined, SteelConnect looks at the network default policies and internet breakout settings. It looks first at the network default policies per zone, then per site, and lastly per organization.
You can use the network default policy and internet breakout settings to centrally specify a WAN preference for a traffic flow, when there is no specific traffic rule in place. For details, see
Networking defaults.
5. After SCM selects the WAN, it chooses the uplink for the WAN. The uplink selection is when the uplink AutoVPN priority and backup only settings come into play. When there is only one uplink for a WAN, that uplink is always used. When there are multiple uplinks per WAN, which is often only the case for Internet uplinks, they are equally balanced by default with failover.
You can demote uplinks to be used as a backup only. For example, you could create 3G and 4G uplinks for use as backups that should only be used if all other active uplinks on the WAN are down. For details, see
Creating uplinks.
Configuring path quality based path selection
SteelConnect provides true path management. You can define traffic flows based on:
•Sites - Specific sites or, if not set, all sites
•Source - Zones, users, groups, and tags
•Destination - Applications, groups, and zones
•Path Preference - Specify the path preference priority for WANS. You can set more than one WAN, for example RouteVPN and MPLS, to ensure that traffic is routed through the RouteVPN first. If RouteVPN isn’t available, traffic is routed through the MPLS network.
•Path Quality - Steers traffic to the best available path based on path quality metrics: latency, jitter, and packet loss.
Path quality profiles
Path quality profiles enable you to steer traffic to the best available link based on latency, jitter, and packet loss metrics for outgoing traffic flows. Path quality picks the path with the highest path preference and best path quality based on the metrics you specify for new and existing connections.
Since path selection must be performed quickly, the service uses the latest latency, jitter, and packet loss values for each tunnel and performs path selection on these. For a detailed definition of latency, jitter, and loss, see
Viewing traffic paths.
You can specify these path quality profile options:
–None - Does not apply latency, jitter, or loss data to the given path. Instead, the system will choose the best path from all configured paths supported by the Site and Zones, regardless if a path preference is defined or not. The system uses path preference only when it needs to choose between equal paths.
–Latency sensitive metrics - Uses latency, jitter, and loss metrics to determine the best possible path for the traffic flow.
–Interactive metrics - Uses latency and loss data only to determine the best possible path for the traffic flow; does not use jitter data.
If you previously set Path Quality override on a prior release of SteelConnect, then the Latency Sensitive metrics option is applied to these legacy traffic path rules.
Threshold buckets
Paths are grouped together using five quality threshold buckets where the worst packet metric is used to calculate the best available path.
The path or uplink is mapped to a bucket and based on this mapping, traffic or flows are steered to the best available path or uplink. This path is determined out of two or three metrics, depending on the setting you have chosen (for example, Interactive has two metrics: latency and loss, whereas Latency sensitive uses latency, jitter, and loss).
New flows | Threshold Buckets |
| 0 | 1 | 2 | 3 | 4 |
Latency | 0-49 ms | 50-149 ms | 150-499 ms | 500-799 ms | => 800 ms |
Jitter | 0-6 ms | 7-14 ms | 15-29 ms | 30-49 ms | => 50 ms |
Loss | 0.0-0.4% | 0.5-0.6% | 0.7-1.4% | 1.5-1.9% | => 2.0% |
For example:
•Link 1 has 49ms latency but 16ms jitter, Link 1 will be in Bucket 2.
•Link 2 has 70ms latency and 7ms jitter, Link 2 will be in Bucket 1.
The preferred link for traffic classified with path rules with Link1 and Link2 as will go through Link 2 as it cumulatively has the least bad metrics.
Existing flows | Threshold Buckets |
| 0 | 1 | 2 | 3 | 4 |
Latency | 0-99 ms | 100-199 ms | 200-599 ms | 600-999 ms | => 1000 ms |
Jitter | 0-11 ms | 12-19 ms | 20-29 ms | 30-74 ms | => 75 ms |
Loss | 0.0-0.6% | 0.7-0.9% | 1.0-1.9% | 2.0-2.9% | => 3.0% |
Once a path is selected by the system, the traffic remains on that path and will not seek a better path until the current path degrades. If traffic lands on the worst path (for example, the last threshold bucket), the system seeks a better path. However, if traffic lands in any other intermediary threshold buckets, it will remain there and not seek a better path until the current path degrades.
SteelConnect rebalances the flow if path quality drops below a certain threshold (which is lower than the new connection threshold) and allows path selection to choose a more suitable path. If the original path recovers, traffic isn’t moved back to that path except for the SteelConnect SDI-5030 gateway.
Path quality profile is off by default (that is, None). If you select a profile, it affects traffic in that traffic path rule only.
If a path preference is specified (for example, RouteVPN and MPLS), the gateway selects from the preference order specified. If a path quality profile is also specified (for example, Latency Sensitive or Interactive Metrics) then the gateway chooses the best path based on measured data metrics from the paths defined in path preferences, except for SDI-5030 gateways, which will choose from all available paths regardless of path preference. If all paths are equal according to the selected path quality profile metrics, then path selection will fall back to path preference.
Path quality profiles are only in effect if a path preference is specified, instructing gateways to direct traffic over the selected paths and ignore paths that are not specified, even if they would provide the better path quality, except for SDI-5030 gateways which will always choose from all available paths regardless of path preference.
Path quality is available only on overlay networks (that is, RouteVPN and additional WANs with encryption turned on). If encryption is turned off for the WAN, but path quality is enabled, then the WAN will only be used if the other paths are down (that is, it falls back to availability based detection).
QoS priority
The QoS priority sets a differentiated services code point (DSCP) value on the traffic path rule. A DSCP value is a packet header mark that indicates the level of service requested for traffic, such as high priority or low delivery. If QoS on the gateway is enabled, then QoS classification and shaping is enforced.
You set the QoS priority on the traffic path rule before you configure QoS on the gateway. For details about configuring QoS on the gateway, see
Configuring QoS.
The QoS priority sets the DSCP value and shapes traffic. You have these options:
•Automatic - No DSCP change. If you want a rule with only a path preference, select Automatic.
•Custom -Sets the DSCP value to a user defined value.
•Urgent - Sets the DSCP value to 46 for Latency Sensitive traffic.
•High - Sets the DSCP value to 30 for Streaming Media traffic.
•Normal - Sets the DSCP value 0 for Best Effort traffic.
•Low - Sets the DSCP value to 8 for Background traffic.
The system looks at traffic path rules on DSCP first and then QoS for gateways.
Traffic path rules and QoS work independently, but they work together if both are enabled. If you have QoS enabled but not traffic path rules, QoS will use the DSCP values as set by the client and server. Any upstream router only sees the overwritten value.
When you specify a custom DSCP value, the system honors the QoS class from the traffic path rule; otherwise, it uses the QoS class from the packet.
To create a traffic path rule
1. Choose Rules > Traffic path rules.
2. Click New path rule.
Creating a traffic path rule
3. Select the position for the rule: Top, Bottom, or After rule #.
4. Optionally, under Site scope, click the search box and select one or more sites from the list to limit the rule to particular sites. If you don’t select a specific site, your rule applies to all sites.
5. Under Users/Source, select a source from the drop-down list (not supported on SDI-5030 gateways).
–All, Registered Users and Devices, and Guests apply globally to these sources.
–Selected zones, classic VPN remote networks, users, devices, and groups or tags, apply to selected sources. You can select multiple zones, users, devices, groups, or tags.
6. Under Application/Target, select a target destination from the list. You have these choices:
–Selected applications or groups - Start to type the application or application group name in the text box, and then select it from the drop-down menu of the available application and application groups. For example, you could steer all Facebook traffic using this choice.
–Selected zones - For example, you can restrict traffic to particular zones using this option.
–DSCP values - You might want to create a path based on a DSCP marking.
–Any - Apply the rule to all applications.
7. Under Path preference, select the WAN path, for example: Internet, MPLS, or RouteVPN. Select more than one WAN path to ensure traffic is routed to your next path preference if your first choice is unavailable.
8. Under Path Quality profile, select one of the following options to override the specified path preference based on latency metrics (that is, latency, jitter, and loss):
–None - Does not apply latency, jitter, or loss data to the traffic path. Path preference is used to determine the best possible path for the traffic flow.
–Latency sensitive metrics - Uses latency, jitter, and loss metrics to determine the best possible path for the traffic flow.
–Interactive metrics - Uses latency and loss data only to determine the best possible path for the traffic flow; does not use jitter data.
9. Optionally, specify a Custom DSCP value or one of the four QoS classes: Urgent, High, Normal, Low. If you want a path rule with only a path preference, leave the setting at Automatic.
10. Click Submit.
Editing traffic path rules
You can edit path rules by clicking the control you want to edit in the Traffic path rules pane, for example:
•Click the traffic path controls (that is, On/Off, Sites, Path preference, Path selection profile, or QoS priority) to display the Edit path rule pane.
•Click the source or destination controls (that is, Users/Source or Applications/Target) to display the corresponding panes for the selected control. For example, if you have chosen an application group, the Application Groups page allows you to delete particular applications from the group. If you specified a DSCP value as the destination/target, you can modify the value in the Edit path rule pane.
SteelConnect reevaluates traffic flows after a traffic rule changes and adjusts path selections accordingly.
To edit traffic path controls
1. In the Traffic path rules pane, click the On/Off, Sites, Path preference, or QoS priority control to display the Edit path rule pane.
Editing path controls
2. Edit the control and click Submit.
To edit Users/Source or Applications/Target controls
1. In the Traffic path rules pane, click either of these controls to display their respective pages. For example, click Applications/Target to display the Application Groups page.
Editing applications or application groups
2. Delete the application you want removed from the group and click Submit.
3. To return to the Traffic path rules pane, choose Rules > Traffic path rules.
Deleting traffic path rules
You can delete a traffic path rule by simply clicking the rule in the Traffic Path Rules list and selecting Delete from Actions drop-down list.
To delete a traffic path rule
1. In the Traffic path rules pane, click the rule you want to delete to expand the page.
Deleting a path rule
2. In the right pane, click Actions and select Delete this rule.
3. Click Confirm.
Traffic path policy example
Suppose you have a salesperson named Ryan. Ryan does most of his sales using the phone and email and he records all of his sales data in Salesforce.com. We want to create a traffic policy that applies to all sites and that ensures:
•Ryan’s Messaging/IM/Email communication traffic is sent over the MPLS with a QoS priority of High and a path quality profile that applies metrics for latency, jitter, and loss.
•Ryan’s sipgate VoIP traffic is sent via the RouteVPN with a QoS priority of Urgent and a path quality profile that applies metrics for latency, jitter, and loss.
•Ryan’s Salesforce.com traffic is sent via the Internet without a QoS priority or a path quality profile.
To create a traffic path policy
1. Choose Rules > Traffic path rules.
2. Click New path rule.
3. Under Position, select Top.
4. Under Users/Source, select Selected Users, Devices, Groups or Tags from the drop-down list.
5. Click the search box and select Ryan salesperson from the drop-down list.
6. Under Applications/Target, select Selected applications and groups from the drop-down list.
7. Click the search box, and type the first few letters of the application: for example, mess for Messaging/IM/Email.
8. Under Path preference, click the search box and select MPLS and select Route VPN as the secondary rule. Path quality based path selection relies on having a failover path that provides better service quality if the first one becomes degraded.
9. Under Path Quality profile, select Latency Sensitive metrics to override the path preference based on latency, jitter, and loss.
10. Under QoS priority, select High from the drop-down list.
11. Click Submit.
Path rule to set a traffic policy
You’ve completed your first path rule that ensures that all Messaging/IM/Email traffic is routed over the MPLS with a QoS priority of High.
12. Click New path rule.
13. Under Position, select After Rule #1.
14. Under Users/Source, select Selected Users, Devices, Groups or Tags from the drop-down list.
15. Click the search box and select Ryan salesperson from the drop-down list.
16. Under Applications/Target, select Selected applications and groups from the drop-down list.
17. Click the search box, and type the first few letters of the application; for example, sip for sipgate VoIP.
18. Under Path preference, click the search box and select RouteVPN and select MPLS as the secondary rule. Path quality based path selection relies on having a failover path that provides better service quality if the first one becomes degraded.
19. Under Path Quality profile, select Latency Sensitive metrics to override the path preference based on latency, jitter, and loss.
20. Under QoS priority, select Urgent from the drop-down list.
21. Click Submit.
Path rule to set a traffic policy for VoIP
You have created a second path rule that applies to all sites where sipgate VoIP traffic is routed over the VPN with a QoS priority of Urgent.
22. Click New path rule.
23. Under Position, select After Rule #2.
24. Under Users/Source, select Selected Users, Devices, Groups or Tags from the drop-down list.
25. Click the search box and select Ryan salesperson from the drop-down list.
26. Under Applications/Target, select Selected applications and groups from the drop-down list.
27. Click the search box, and type the first few letters of the application; for example, sales for Salesforce.com.
28. Under Path preference, click the search box and select Internet.
29. Under Path Quality profile, select None. The Salesforce.com traffic is sent via the Internet without a path quality profile that applies latency sensitive metrics.
30. Under QoS priority, select Automatic from the drop-down list. The Salesforce.com traffic is sent via the Internet without a QoS priority.
31. Click Submit.
Path rule to set a Salesforce traffic policy
You’ve created a final rule that ensures that the Salesforce.com traffic is sent over the internet and it doesn’t have a QoS priority. Your traffic policy appears as shown in
Complete traffic policy for a salesperson.
Complete traffic policy for a salesperson
Viewing traffic paths
You can view if a path is up or down after clicking a site marker in the dashboard. A green line indicates that the VPN tunnel is successfully established. A red dashed line indicates that the VPN tunnel can’t be established. The lines automatically update if problems arise. For details on the dashboard, see
Viewing your topology.
Monitoring path quality
SteelConnect measures the health and connectivity of a VPN tunnel between two sites by collecting information about VPN endpoints. These measurements provide important information about your VPN deployment. Path quality reports metrics on established and functional tunnels. A path quality status window reports on key metrics such as tunnel latency, jitter, packet loss, and throughput. By default, path quality measures tunnel statistics every second or 64 packets transmitted and sends them to SCM every minute.
To view path status
•On the dashboard map, click a site marker.
•Click a green line indicating a path.
A status window displays real-time tunnel statistics for the selected path. When appliances at the two sites are using multiple uplinks and multiple WANs, information about all of the tunnels appears.
Monitoring path quality
The path status includes this information:
•Outbound and inbound throughput - Displays the total throughput levels and the total one-way throughput levels for each QoS class. The class metrics appear side-by-side for immediate comparison. Path quality calculates the throughput by sampling both encrypted and decrypted packets and subtracting any retransmitted packets from the total, known as
TCP goodput. For details on the QoS classes, see
How does QoS for gateways work?.
•Path quality metrics - Displays path quality metrics: latency, jitter, and packet loss. For all quality measurements, a low value is best.
•Latency - Measures the amount of delay (in bits per second) for a packet traveling from one site to another and back again, known as round-trip time (RTT).
•Jitter - Measures any change in one-way packet delay. When the exact amount of delay occurs from one site to another, there is zero jitter. When the delay is inconsistent, jitter is the amount of delay that varied from previous measurements. Jitter is most likely to occur on either slow or heavily congested links.
•Packet Loss - Measures any one-way packet loss. Any number indicates a possible problem.
Click the double arrows in the top left corner of the status window to see tunnel statistics in the reverse direction.