Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Part 3: Configure Application Quality of Experience with SD-WAN

Overview

In this section you configure Application Quality Experience (AppQoE) on the SRX. AppQoE improves the user experience at the application level. Performance probes constantly monitor quality of service parameters and Service Level Agreement (SLA) compliance of application traffic. The result is application traffic always uses the most SLA-compliant link available.

Let us consider the applications listed in Table 1. For this example the Office365, Salesforce, and Zoom applications are deemed business-critical for the organization. All critical applications should be routed through the private WAN link when it meets the application’s SLA requirements. Critical applications are also use the LTE link when all other links are down.

The remaining applications use the broadband Internet access link as the primary link. Because only business-critical applications are able to use the LTE backup link, the noncritical applications are inaccessible when only the LTE connection is available.

Table 1: Typical Applications Used in a Branch Office

Application

Primary Link

Secondary Link

Business Critical?

Office365

Private WAN

Broadband Internet

Yes

Salesforce

Private WAN

Broadband Internet

Yes

Zoom

Private WAN

Broadband Internet

Yes

Slack

Broadband Internet

Private WAN

No

GoToMeeting

Broadband Internet

Private WAN

No

Dropbox

Broadband Internet

Private WAN

No

Skype

Broadband Internet

Private WAN

No

Youtube

Broadband Internet

Private WAN

No

Note:

You configure AppQoE for one business critical and one noncritical application to keep the example focused. You can easily adapt the configuration to support additional applications by specifying the desired probe type and target domain name or IP address.

Step by Step Procedure

  1. Create time-performance monitoring probes for Office 365. Office 365 is a critical application as per Table 1. We set up a probe to test the connectivity to the IP address used by Office365, specifically 40.97.223.114. The probe is configured to send 5 ping-based probes, 6 seconds apart on the private WAN link. We also configure the thresholds that should not be violated, such as the loss of 5 successive probes, or a probe round trip transit time (RTT) exceeding 300000 microseconds. The IP address of the gateway on interface ge-0/0/3 is 192.168.220.1.

    Tip:

    You can enter the probe target as an IP address or using a domain name. If a name is specified the Junos Software automatically resolves it to the corresponding IP address in the configuration. This example shows ICMP based probes. Other probe types exist, for example, an HTTP-get. Not all sites respond to ICMP echo request (Ping) messages. Be sure to use a probe type supported by the application provider.

  2. Create the second probe for the same application to probe the secondary link using the secondary interface. The IP address of the default gateway on the broadband Internet link is 172.16.1.1.

  3. In a similar fashion, you create two probes for the Skype application. Skype is not a business critical application as per Table 1. We require a more stringent service level guarantee for this real-time (yet non-critical) application. Specifically, you configure a shorter probe interval of 1 second and a shorter RTT threshold of 60000 microseconds.

    Note:

    We set up the primary and secondary probes on the interface based on whether the application is business critical. The interface and the IP address for the primary probe for noncritical applications (Skype) is different than the probe for the critical application (Office365).

  4. Create a routing instance for each application. We configure an application’s route for the primary link with a lower preference value than the backup link. Routes with a lower preference value have preference over higher value routes. You include the LTE backup interface only for the business-critical applications.

    The routing instance for Office365 sets a route preference value of 10 for the private WAN gateway (most preferred route). A preference value of 20 for the broadband Internet link (next preferred route). And a preference value of 30 for the LTE backup link (the least preferred route).

  5. Configure the routing instances for the Slack application in a similar pattern. This noncritical application does not include the LTE interface in the routing instance. Omitting the LTE interface is what prevents noncritical applications from using the LTE backup link. Also note how the static route preferences cause this application use the broadband Internet as its primary link.

  6. Configure IP monitoring policies for the applications. The goal of the policies is to dynamically change the metric of the default routes in the routing instances. The policies operate on a per-probe basis.

    In this step, we create the IP monitoring policy for the Office365 application. For Office365, we configure two probes and create two policies—one for each probe. When the probe detects that the application traffic has violated the configured threshold on a link, the policy changes the preference of the routes. The policy decreases the metric for the second best link to 2. This change directs traffic in the routing instance to the backup link.

    For example, when the probe identifies that the primary link for Office365, the private WAN link, does not meet the requirements for RTT and loss, the policy changes the metric of the gateway for the broadband Internet link (next preferred route) to a value of 2.

  7. Configure the IP monitoring policy for the secondary probe for Office365.

    Note:

    The next-hop address is the IP address for the primary private WAN link.

  8. Configure the IP monitoring policy for the Slack application.

  9. Configure an advanced policy-based routing (APBR) profile. Your APBR profile matches both applications used in this example. The profile redirects matching traffic to their respective routing instance. The profile uses rules, with each rule covering one application and one routing instance. For this example, we configure a rule named office365_rule to match all the traffic for the application named "junos:OFFICE365-CREATE-CONVERSATION” and redirect the traffic to the routing instance named office365_RInstance. The Slack application is handed in like fashion.

    Note:

    APBR requires an appid-sig license. Without the license you will get a commit error. See the requirements section for details.

    Note:

    To maintain application continuity and not impact users, we wish to disallow mid-session path changes for established sessions. You set the max-route-change parameter to 0 to prevent changes to established sessions.

    Tip:

    The Junos Software supports an extensive list of dynamically recognized applications. Application Identification provides visibility into the applications on your network, showing you how the application works, its behavioral characteristics, and its relative risk. App ID uses numerous mechanisms to detect the applications on your network. App ID works regardless of the port, protocol, encryption (TLS/SSL or SSH), or other evasive tactics. For more information see Application Identification.

  10. Configure a protocol-independent group of routing tables. This configuration copies the interface routes to the various application routing instances. Copies of these route are what allows a given instance to use the private WAN or the broadband Internet links. Recall that you defined both of these interfaces in the main routing instance.

  11. Add the newly created profile apbr_profile to the security zone trust. This configuration applies the profile to the traffic in the zone.

  12. Commit the configuration and return to operational mode.

Verify Application Quality of Experience

Purpose

Confirm that APBR is working as per the objectives of this example.

Action

Generate a mix of business critical and noncritical traffic from a wired or wireless client. Then issue the commands in this section to verify that ABPR is working properly.

Start by confirming RPM probes are successful on both primary and secondary links. To save space, we show only the probes for the critical application. All probes should be successful at this time. Display the results of the RPM probes using the show services rpm probe-results owner office365_rpm_primary (and secondary) commands.

The output confirms that the critical business application probes are currently succeeding on both the primary and secondary links. You expect similar results for the noncritical application probes, with the primary and secondary interfaces reversed.

Next, display a routing instance to verify forwarding state when both primary and secondary interfaces are operational. Issue the show route table <instance-name> command for both the critical and noncritical applications.

The output confirms that traffic classified as Office 365 uses the private WAN link. As a business critical application, the routing instance has both a secondary and tertiary next hop. When the first two next hops become unavailable critical traffic falls over to the LTE modem. In contrast, the noncritical application is using the broadband Internet link to forward traffic. If that next hop becomes unavailable the instance direct traffic to the private WAN. The LTE modem is not listed in this routing instance. This omission prevents noncritical application from using the LTE link.

Recall that the SLA monitoring probes flow through the Internet to the application provider. The end-to-end nature of the probes allows the SRX to measure the end-to-end performance of the application. The measurement of the "application level experience" stands in contrast to simply detecting link or next hop failures based on interface status or bidirectional forwarding detection (BFD), respectively.

Optional: Disrupt RPM probes to confirm critical traffic uses the broadband Internet link. You can simulate SLA probe failures with a firewall filter applied in the output direction on the private WAN interface on the SRX device.

With the filter in place on the private WAN link, you expect to find the critical application forwarded over the broadband Internet link.

With the primary probes now failing, the SLA monitoring policy has adjusted the static route preference in the critical application routing instance. The result is the critical traffic flows over the broadband Internet link. This behavior confirms proper operation of IP SLA performance monitoring.

Note:

Don’t forget to roll back the firewall filter change at the SRX! Once rolled back, you expect to see the critical application routing instance again forwarding over the private WAN link.

You can monitor APBR traffic statistics with the show security advance-policy-based-routing statistics command.

The output displays the statistical details for APBR. The details include the number of sessions processed by the APR rule, and the number of times the application traffic matches the APBR profile (rule hit).

Meaning

The commands and output shown in this section confirm that APBR is working properly on the SRX services gateway. Your new branch office managed by the Juniper Mist Cloud is ready for business.