Defining Traffic Rules

Traffic rules (or path selection) is a granular set of rules that direct traffic over multiple WANs: internet, RouteVPN, MPLS, and the underlay. 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.

•can select the best overlay path based on path preference and path quality metrics (that is, latency, jitter, and loss).

SteelConnect attempts to perform application detection on the first packet detected by the gateway. The SteelConnect gateway searches for the hostname from the local DNS cache and sends the request to the application controller server. If the gateway doesn’t locate a DNS entry in the cache, it uses the IP address.

•For traffic destined to remote zones, the SteelConnect gateway further inspects the packets after the initial TCP handshake and reclassifies the traffic if needed. If the traffic is reclassified, the gateway reapplies all traffic rules.

•For internet-based traffic, further reclassification is also performed; however, when internet-based traffic is reclassified, the traffic rules are not reapplied.

Traffic 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 rules only apply on the client gateway and not on the server gateway a second time.

For overlay traffic, 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. Underlay traffic on the return path, however, is independently routed and does not necessarily traverse the same path as the gateway that initiated the connection.

Traffic rules take effect on different WANs, not uplinks. For example, it isn’t possible to define traffic rules for two internet connections because they are both on the same WAN.

By default, on SDI-130, SDI-330, and SDI-1030 gateways, all traffic rules fall through; that is, if traffic matches an MPLS rule defined with unreachable paths, then it will continue to fall through to the next rule match until one is found with reachable paths. If no rule is found, the default rule is applied. You can disable the fall through feature to prevent further evaluation of rules beyond the first match. For details, see To create a traffic rule.

By default, on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances and the SDI-2030 and SDI-5030 gateways, all traffic rules fall through to the:

•organization default for site-to-site traffic on the overlay and underlay when all configured paths are unavailable.

•zone, site, and organization internet breakout preferences for internet traffic when all configured paths are unavailable.

When you create traffic rules, they override the organization internet breakout and WAN usage preferences that you set when you created an organization.

2. To steer traffic flows between WANs, SteelConnect selects which WAN (for example, MPLS, RouteVPN, Internet, or Underlay) 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 a path 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 rules defined, SteelConnect checks the network default policies and internet breakout settings. SteelConnect checks the network default policies in this order: 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 the SD-WAN controller selects the WAN and applies a path preference, when there is more than one similar tunnel available on the same WAN, it chooses the uplink for the WAN. The uplink selection is when the uplink AutoVPN priority and backup-only settings come into play. To distribute traffic flows on secure overlay tunnels, the SD-WAN controller considers these settings to set tunnel priorities:

Source uplink	Destination uplink
Is the uplink active or backup? What is the AutoVPN priority?	Is the uplink active or backup? What is the AutoVPN priority?

Tunnels are considered similar if they belong to the same WAN and have the same priority. The SD-WAN controller considers the similarities to distribute traffic flows among similar tunnels.

When there is only one uplink for a WAN, that uplink is always used.

All new traffic flows are subject to flow distribution across all similar tunnels; the SteelHead SD 570-SD, 770-SD, and 3070-SD appliances and the SDI-2030 select one tunnel among several similar tunnels at random using a uniform random distribution function.

Flow distribution for internet traffic across similar uplinks is not supported on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances.

Existing flows remain on the selected tunnel/uplink as long as the tunnel is up; if the selected tunnel/uplink becomes unavailable, the flow is subject to path selection and flow distribution.

When there are multiple uplinks available on the same WAN, traffic flows are randomly distributed as evenly as possible between all uplinks of the same type (active or backup), and the same AutoVPN priority. The uplinks are equally balanced by default with failover. SCM distributes the traffic flows on SDI gateways based on the type of traffic:

•RouteVPN traffic is distributed on uplinks of the same priority using a source IP address and destination IP address hashing algorithm.

Traffic flow distribution is different on the SDI-2030 gateway and on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances. On these appliances, SteelConnect distributes all traffic flows in a purely uniform random distribution. This ensures that all similar uplinks are used equally, even when the traffic is from one client.

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. The backup-only uplink setting is not available on a SDI-2030 gateway or on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances. On an SDI-5030 gateway, data center uplinks are always active by design.

SteelConnect doesn’t distribute traffic flows using uplinks on any traffic flows that match a traffic rule using path quality-based path selection.

•Path Quality profile - Steers traffic to the best available path based on path quality metrics: latency, jitter, and packet loss.

•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 profiles 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 best path quality based on the metrics evaluated on new and existing connections.

Because 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 packet loss, see Viewing traffic paths.

•None - Does not apply latency, jitter, or packet 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 in terms of longest prefix match; that is, the system uses path preference if a gateway has a choice between two overlays to reach a /24 subnet.

•Latency sensitive metrics - Uses latency, jitter, and packet loss data to determine the best possible path for the traffic flow.

•Interactive metrics - Uses latency and packet 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 rules.

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 uses 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%

The preferred link for traffic classified with rules with Link 1 and Link 2 will go through Link 2 as it cumulatively has the better 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%

After 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 reevaluates an existing flow if path quality breaches a certain threshold (which is less stringent 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.

Path quality profile is off by default (that is, None). If you select a profile, it affects traffic matching that 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. An SDI-5030 gateway will always choose from all available paths regardless of path preference.

In SteelConnect 2.11, 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). Traffic rules can be added to enable path quality on a single WAN.

The QoS priority sets a differentiated services code point (DSCP) value on the traffic 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 rule before you configure QoS on the gateway. For details on configuring QoS on the gateway, see Configuring QoS.

Traffic rules and QoS work independently, but they work together if both are enabled. If you have QoS enabled but not traffic 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 rule; otherwise, it uses the QoS class from the packet.

When there is no user traffic, IPsec sends active probes between the peers in a round-robin fashion through these four DSCP values:

When there is user traffic, additional measurement requests are attached directly on the packets of the user traffic.

5. Optionally, under Site scope, click the search selector 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.

–Selected Users, Devices, Groups, or Tags. Apply to selected sources. You can select multiple users, devices, groups, or tags.

–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 list of the available application and application groups. For example, you could steer all Facebook traffic using this choice.

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. Under Path preference, select the WAN path: for example, Internet, MPLS, RouteVPN, or Underlay. Underlay is visible only when the Path Quality profile is set to none. Select more than one WAN path to ensure traffic is routed to your next path preference if your first choice is unavailable.

Selecting Underlay provides the flexibility to override the path selection logic based on Longest Prefix Match (LPM) to prefer an underlay path for certain traffic in the event that the overlay and underlay paths have an equal LPM match.

Traffic matching a rule with the path preference set to Underlay can be routed on the WAN underlay only when the Path Quality profile setting is None.

SDI-5030 gateways always choose from all available overlay paths regardless of path preference.

10. By default, all traffic rules fall through; that is, if you have an MPLS rule and MPLS isn’t reachable, then the traffic flow falls through to the next matching rule or the network default routing. If no rule is found, then the traffic reverts to the default rule.

For SDI-130, SDI-330, and SDI-1030 gateways, next to Rule fall through, click On to have traffic fall through to the next matching rule or the networking default settings when all configured paths are unavailable.

For SteelHead SD 570-SD, 770-SD, and 3070-SD appliances and SDI-2030 and SDI-5030 gateways, next to Rule fall through, click On to have traffic fall through to the:

•organization default for site-to-site traffic on the overlay and underlay when all configured paths are unavailable.

•zone, site, and organization internet breakout preferences for internet traffic when all configured paths are unavailable.

Click Off to drop the packet when the traffic path is unavailable (all SteelHead SD appliances and SDI gateways).

11. Optionally, specify a Custom DSCP value or one of the four QoS classes: Urgent, High, Normal, Low. If you want a rule with only a path preference, leave the setting at Automatic.

•Click the traffic path controls (that is, On/Off, Sites, Path preference, Path selection profile, or QoS priority) to display the Edit 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 traffic rule pane.

1. In the Traffic rules pane, click the On/Off, Sites, Path preference, or QoS priority control to display the Edit traffic rule pane.

1. In the Traffic rules pane, click either of these controls to display their respective pages. For example, click Applications/Target to display the Application Groups page.

You can delete a traffic rule by selecting the rule in the Traffic Rules list and selecting Delete from Actions drop-down list.

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.

5. For this example, leave the site scope at its default setting, because you want to apply the traffic rule to all sites.

9. Click the search selector, and type the first few letters of the application: for example, mess for Messaging/IM/Email.

10. Under Path Quality profile, select Latency Sensitive metrics to override the path preference based on latency, jitter, and loss.

11. Under Path preference, click the search selector 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.

You’ve completed your first traffic rule that routes all Messaging/IM/Email traffic over the MPLS with a QoS priority of High.

20. Click the search selector, and type the first few letters of the application: for example, sip for sipgate VoIP.

21. Under Path preference, click the search selector 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.

22. Under Path Quality profile, select Latency Sensitive metrics to override the path preference based on latency, jitter, and loss.

You’ve created a second traffic rule that applies to all sites where sipgate VoIP traffic is routed over the VPN with a QoS priority of Urgent.

30. Click the search selector, and type the first few letters of the application: for example, sales for Salesforce.com.

32. 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.

33. Under QoS priority, select Automatic from the drop-down list. The Salesforce.com traffic is sent via the internet without a QoS priority.

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.

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.

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.

•On the dashboard map, click a green line indicating a path for deployments with less than 16 sites. For a deployment with more than 16 sites, click a site marker.

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.

•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.

Click the double arrows in the top left corner of the status window to see tunnel statistics in the reverse direction.