Article by Maskym Dmitriiev
1. Introduction
This article presents configuration steps and guidance of how to configure DIA (Direct Internet Access) traffic steering. This functionality brings load balancing and QoE (Quality of Experience) benefits when local Internet breakout is used as opposite to a central Internet breakout via the HUB or Data Center. In addition, it covers session re-evaluation technique. This brings an enhancement value into a traffic steering component for all existing sessions. Often it is required during failover as well as during link degradation conditions when WAN connection is non-compliant based on SLA metric report or link performance degradation is detected.2. Design topology and Configuration steps
Below diagram represents typical Branch Edge component with multihomed ISP connection. The same steps described in the document are applicable for the Branch where Versa Active/Active HA (High Availability) is implemented on a Branch Edge. Additionally, more than two WAN uplinks are supported.
Business use case is to leverage 2 local Internet connections on the Branch in order to access SaaS applications reachable from Internet. System Administrator would like to monitor local Internet connections availability and performance metrics and use ISP 1 and ISP 2 connections for load sharing the traffic in a steady state. In case of failover or performance degradation on either of ISPs, system Administrator should prefer only ISP with metrics that are compliant to expected SLA.
Note, it is also possible to configure static priorities in order to make one ISP with a higher preference comparing to another ISP while still rely on availability and performance metrics to select Active ISP for the traffic forwarding.
To configure automated traffic steering policies on VOS for DIA, administrator needs to follow below steps:
• Create SaaS monitors
• Create SLA profiles which consider a baseline SaaS monitor metrics
• Create SDWAN Forwarding Profile to select WAN link priorities based on real time performance metrics
• Create SDWAN policy to match selected traffic on which DIA steering rules should be applied
• Adjust CGNAT workflow default configuration to eliminate session pinning in the NAT flow table
This implementation is applicable with VOS running 22.x and higher software version.
3. Workflow configuration prerequisites
Before we look into configuration details of targeted design requirements from the previous section, we should make sure that Workflow Template enables DIA or local Internet breakout for selected Internet WAN links.
Open branch workflow template under Workflows -> Template -> Templates.
Make sure that under Tunnels section the split tunnel for the desired LAN VR is enabled with Direct Internet Access check box. In additional, for routing based load balancing, enable Load Balance option.
4. Device Template Configuration example
Once the workflow template is deployed with DIA enabled, we can proceed to apply intelligent DIA steering configuration with session re-evaluation option.
Navigate to Configuration -> Templates -> Device Template and open created configuration template from workflow. Note, similar configuration can be achieved with a service template in order to reuse it in multiple Device Groups if applicable in your SDWAN design.
First step is to create SaaS monitors. Navigate to Networking -> SaaS App Monitor and click +Add to create a new SaaS monitor.
In this section we should create Active SaaS monitors per WAN transport that is being used for a desired traffic. Active SaaS monitor collects performance metrics using selected WAN links and uses those metrics to help determine the best path to a SaaS application. VOS supports local and remote SaaS monitor. In this article we will focus on a local SaaS monitor for DIA traffic.
VOS supports ICMP, TCP and HTTP monitor types. In this example ICMP monitor configured with google DNS destination. If ICMP is not a feasible option, alternative monitor type can be selected.
*Note, in 22.x active HTTPs SaaS monitor is not available. In case of L7 monitor requirement, destination SaaS application should accept HTTP request.
*Note, VOS supports number of pre-defined SaaS applications that can be used as a destination monitor as well.
Once SaaS monitors are configured one per WAN transport, the next step is to define SLA profiles. For DIA traffic, SLA profile supports packet loss and latency metrics. Administrator can select lowest packet loss / latency link or set thresholds for acceptable latency and packet loss levels as per application requirement. In case of lowest latency / packet loss in order to load share traffic between WAN links the metric characteristics should not be different for more than 10% between WAN Transports and WAN circuit priorities should be equal.
Navigate to Services -> SDWAN -> SLA Profiles. Click +Add to add a new SLA Profile. In this scenario Administrator needs to create 2 SLA Profiles, one per transport as different SaaS monitors are being used. Click SaaS App Monitor tab. Select created SaaS App Monitor and set desirable SLA. In this example Administrator set Maximum Latency 100 msec. In this case VOS will measure performance metrics to selected SaaS application and WAN transport with latency lower than 100 msec will be compliant, otherwise it will become violated and excluded for data plane traffic forwarding.
* SLA profile for INET2 has similar configuration.
Next step to create SDWAN Forwarding Profile for DIA traffic. Click Forwarding profile menu.
Click +Add to create a new Forwarding Profile. Click on Nexthop tab, this is where DIA nexthop priorities are configured and created SLA profile is associated.
Select Nexthop selection method as Weighted Round Robin, which will do load balancing of all flows among the highest-priority SLA-compliant paths. Click to enable “Nexthop Re-Evaluate”. This option will enable automatic failover of existing sessions in case WAN Transport will become violated. Flows that moved to a new WAN Transport will remain on that WAN Transport as long as it is SLA-compliant.
Next, click + to add nexthop WAN Transports. In this example Administrator set equal priorities for INET1 and INET2 to load balance DIA data traffic across available Internet connections as long as those are compliant with defined SLA metrics.
Inside Nexthop Priorities menu Administrator need to set a Name, WAN Transport Priority, select WAN Transport and associated with it SLA Profile that was created in a previous step. Configuration for INET2 will be the same.
*Note, static priority can be different, for example if INET2 will have Priority 2, then traffic will be sent over INET1 only as long as it is compliant with defined SLA metrics.
Next step is to create SDWAN Policy for selected DIA traffic. This should match desired data plane traffic for which it is critical to select SLA compliant WAN Transports as per metrics defined in above configuration.
*Note, order of the policy rules is important. Traffic that matches higher policy (first match) will be enforced with a forwarding profile applied inside this policy and next policies will not be evaluated.
Navigate to SDWAN -> Policies -> Rules and click +Add to create new SDWAN Policy.
Using Policy Rule Administrator can match traffic based on source / destination zone, IP, L4 information, Applications, URLs, IoT devices, Users/Groups, QOS values etc. In this example Administrator will match traffic coming into Intf-LAN-Zone which is LAN facing interface and it is iPerf traffic (TCP and UDP) used for testing purposes.
Source zone match
iPerf service match
Another example can be predefined Salesforce SaaS Application Group match.
The last step is to adjust default CGNAT configuration that is created by workflow. By default NAT configured to happen in the LAN Transport VR, which we need to change to WAN Transport VR. It is required because VOS will create NAT entry for the session in the LAN Transport VR where DIA traffic steering will happen. As a result, in case of existing session re-evaluation should happen due to initially selected WAN Transport becomes SLA violated, CGNAT dependant entry in LAN Transport VR won’t allow to properly change WAN Transport or smoothly redirect existing session to a new WAN Transport that is SLA compliant.
Navigate to Services -> CGNAT -> Rules and open DIA rule for every WAN Transport that is used for DIA traffic steering.
Under Match Tab, by default Destination Zone is set. Click Destination and remove existing zone. It should be empty.
Next, click Source and select Source Zone which matches traffic in WAN Transport VR coming from LLAN Transport VR. In this example it will be W-ST-Versa-LAN-INET, where W-ST means traffic comes from LAN VR to WAN VR in a split tunnel concept, Versa is a tenant name, LAN is a network name in LAN Transport VR and INET is a network name in WAN Transport VR.
The same configuration should be done for all DIA CGNAT Rules used for a data plane.
5. Verification steady state
INET1 and INET2 both have the same priority, therefore in a steady state traffic for selected application hosted on Internet should be load balanced. To verify, firstly that administrator can check session extensive details. Open VOS appliance view and navigate to Monitor -> Services -> Sessions and click filter icon on the left side as highlighted below.
In the session filter select Extensive view and filter your application using Session Search Criteria options. As in below example there are multiple sessions initiated for the same application behind VOS device and all of them are equally distributed among INET1 and INET2 links.
To verify that both INET 1 and INET2 are SLA compliant path navigate to Monitor -> Networking -> SaaS App and select monitor type local, brief or detail view and your SaaS monitor.
In this case both INET1 and INET2 have latency less than 100 msec, therefore they are both SLA compliant links.
Another useful method to gather information on nexthop statistics is under Monitor -> Services -> SDWAN -> Policies. Select Default SDWAN policy and Nexthop Statistics view. Next, click on view for selected rule name. Here administrator can check nexthop status, if it is active which means SLA compliant, etc for every WAN Transport.
6. Verification failover condition
Now lets consider performance degradation happened on INET1 connection where latency violate expected SLA. Navigate to Monitor -> Networking -> SaaS App and select monitor type local, brief or detail view and INET1 SaaS monitor. SaaS App monitor detected change of underlay performance.
Now it is expected that INET1 should become violated. Navigate to Monitor -> Services -> SDWAN -> Policies. Select Default SDWAN policy then Nexthop Statistics view and open rule which set SLA compliance for selected applications. This way Administrator can detect SLA violation using INET1 as below.
Because INET1 is violated, nexthop is not active for the forwarding decision. Now, all iPerf session should use INET2 only, as the output below confirms. Navigate to Monitor -> Services -> Sessions and click filter icon. For session detail Administrator can see that all traffic use INET2.
*Note, with nexthop re-evaluate option, all existing sessions will also gradually move to INET2.
7. Conclusions
In this article we demonstrated how efficiently leverage DIA traffic steering policies on VOS Edge appliance considering Internet performance metrics.
