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.
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 |
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
-
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.
set services rpm probe office365_rpm_primary test office365_test_primary probe-type icmp-ping set services rpm probe office365_rpm_primary test office365_test_primary target address 40.97.223.114 set services rpm probe office365_rpm_primary test office365_test_primary probe-count 5 set services rpm probe office365_rpm_primary test office365_test_primary probe-interval 6 set services rpm probe office365_rpm_primary test office365_test_primary thresholds successive-loss 5 set services rpm probe office365_rpm_primary test office365_test_primary thresholds rtt 300000 set services rpm probe office365_rpm_primary test office365_test_primary destination-interface ge-0/0/3.0 set services rpm probe office365_rpm_primary test office365_test_primary next-hop 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.
-
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.
set services rpm probe office365_rpm_secondary test office365_test_secondary probe-type icmp-ping set services rpm probe office365_rpm_secondary test office365_test_secondary target address 40.97.223.114 set services rpm probe office365_rpm_secondary test office365_test_secondary probe-count 5 set services rpm probe office365_rpm_secondary test office365_test_secondary probe-interval 6 set services rpm probe office365_rpm_secondary test office365_test_secondary thresholds successive-loss 5 set services rpm probe office365_rpm_secondary test office365_test_secondary thresholds rtt 300000 set services rpm probe office365_rpm_secondary test office365_test_secondary destination-interface ge-0/0/2.0 set services rpm probe office365_rpm_secondary test office365_test_secondary next-hop 172.16.1.1
-
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).
set services rpm probe skype_rpm_primary test skype_test_primary probe-type icmp-ping set services rpm probe skype_rpm_primary test skype_test_primary target address 13.107.8.2 set services rpm probe skype_rpm_primary test skype_test_primary probe-count 5 set services rpm probe skype_rpm_primary test skype_test_primary probe-interval 1 set services rpm probe skype_rpm_primary test skype_test_primary thresholds successive-loss 5 set services rpm probe skype_rpm_primary test skype_test_primary thresholds rtt 60000 set services rpm probe skype_rpm_primary test skype_test_primary destination-interface ge-0/0/2.0 set services rpm probe skype_rpm_primary test skype_test_primary next-hop 172.16.1.1 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-type icmp-ping set services rpm probe skype_rpm_secondary test skype_test_secondary target address 13.107.8.2 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-count 5 set services rpm probe skype_rpm_secondary test skype_test_secondary probe-interval 1 set services rpm probe skype_rpm_secondary test skype_test_secondary thresholds successive-loss 5 set services rpm probe skype_rpm_secondary test skype_test_secondary thresholds rtt 60000 set services rpm probe skype_rpm_secondary test skype_test_secondary destination-interface ge-0/0/3.0 set services rpm probe skype_rpm_secondary test skype_test_secondary next-hop 192.168.220.1
-
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).
set routing-instances office365_RInstance instance-type forwarding set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop 192.168.220.1 preference 10 set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop 172.16.1.1 preference 20 set routing-instances office365_RInstance routing-options static route 0/0 qualified-next-hop dl0.0 preference 30
-
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.
set routing-instances slack_RInstance instance-type forwarding set routing-instances slack_RInstance routing-options static route 0/0 qualified-next-hop 172.16.1.1 preference 10 set routing-instances slack_RInstance routing-options static route 0/0 qualified-next-hop 192.168.220.1 preference 20
-
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.
set services ip-monitoring policy office365_ipm_primary match rpm-probe office365_rpm_primary set services ip-monitoring policy office365_ipm_primary then preferred-route routing-instances office365_RInstance route 0/0 next-hop 172.16.1.1 set services ip-monitoring policy office365_ipm_primary then preferred-route routing-instances office365_RInstance route 0/0 preferred-metric 2
-
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.
set services ip-monitoring policy office365_ipm_secondary match rpm-probe office365_rpm_secondary set services ip-monitoring policy office365_ipm_secondary then preferred-route routing-instances office365_RInstance route 0/0 next-hop 192.168.220.1 set services ip-monitoring policy office365_ipm_secondary then preferred-route routing-instances office365_RInstance route 0/0 preferred-metric 2
-
Configure the IP monitoring policy for the Slack application.
set services ip-monitoring policy slack_ipm_primary match rpm-probe slack_rpm_primary set services ip-monitoring policy slack_ipm_primary then preferred-route routing-instances slack_RInstance route 0/0 next-hop 192.168.220.1 set services ip-monitoring policy slack_ipm_primary then preferred-route routing-instances slack_RInstance route 0/0 preferred-metric 2 set services ip-monitoring policy slack_ipm_secondary match rpm-probe slack_rpm_secondary set services ip-monitoring policy slack_ipm_secondary then preferred-route routing-instances slack_RInstance route 0/0 next-hop 172.16.1.1 set services ip-monitoring policy slack_ipm_secondary then preferred-route routing-instances slack_RInstance route 0/0 preferred-metric 2
-
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.
set security advance-policy-based-routing tunables max-route-change 0 set security advance-policy-based-routing profile apbr_profile rule office365_rule match dynamic-application junos:OFFICE365-CREATE-CONVERSATION set security advance-policy-based-routing profile apbr_profile rule office365_rule then routing-instance office365_RInstance set security advance-policy-based-routing profile apbr_profile rule slack_rule match dynamic-application junos:SLACK set security advance-policy-based-routing profile apbr_profile rule slack_rule then routing-instance slack_RInstance
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.
-
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.
set routing-options interface-routes rib-group inet apbr_rib_group set routing-options rib-groups apbr_rib_group import-rib inet.0 set routing-options rib-groups apbr_rib_group import-rib office365_RInstance.inet.0 set routing-options rib-groups apbr_rib_group import-rib slack_RInstance.inet.0
-
Add the newly created profile apbr_profile to the security zone trust. This configuration applies the profile to the traffic in the zone.
set security zones security-zone trust advance-policy-based-routing-profile apbr_profile
-
Commit the configuration and return to operational mode.
commit and quit
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.
root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_primary Owner: office365_rpm_primary, Test: office365_test_primary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 79 Destination interface name: ge-0/0/3.0 Test size: 5 probes Probe results: Response received Probe sent time: Mon Jun 7 15:58:28 2021 Probe rcvd/timeout time: Mon Jun 7 15:58:28 2021, No hardware timestamps Rtt: 3321 usec, Round trip jitter: -185 usec Round trip interarrival jitter: 1026 usec . . . root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_secondary Owner: office365_rpm_secondary, Test: office365_test_secondary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 79 Destination interface name: ge-0/0/2.0 Test size: 5 probes Probe results: Response received Probe sent time: Mon Jun 7 15:58:37 2021 Probe rcvd/timeout time: Mon Jun 7 15:58:37 2021, No hardware timestamps Rtt: 3402 usec, Round trip jitter: 73 usec Round trip interarrival jitter: 424 usec . . .
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.
root@Mist-SRX-GW# show route table office365_RInstance office365_RInstance.inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/10] 03:34:36 > to 192.168.220.1 via ge-0/0/3.0 [Static/20] 03:11:34 > to 172.16.1.1 via ge-0/0/2.0 [Static/30] 03:34:36 > via dl0.0 10.10.20.0/24 *[Direct/0] 03:34:36 > via ge-0/0/4.20 10.10.20.1/32 *[Local/0] 03:34:36 Local via ge-0/0/4.20 10.10.30.0/24 *[Direct/0] 03:34:36 > via ge-0/0/4.30 . . . root@Mist-SRX-GW# show route table office365_RInstance slack_RInstance.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/10] 03:23:32 > to 172.16.1.1 via ge-0/0/2.0 [Static/20] 03:46:34 > to 192.168.220.1 via ge-0/0/3.0 10.10.20.0/24 *[Direct/0] 03:46:34 > via ge-0/0/4.20 10.10.20.1/32 *[Local/0] 03:46:34 Local via ge-0/0/4.20 10.10.30.0/24 *[Direct/0] 03:46:34 > via ge-0/0/4.30 10.10.30.1/32 *[Local/0] 03:46:34 . . .
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.
set interfaces ge-0/0/3 unit 0 family inet filter output block_ping set firewall filter block_ping term 1 from destination-address 40.97.223.114/32 set firewall filter block_ping term 1 from protocol icmp set firewall filter block_ping term 1 then count ping set firewall filter block_ping term 1 then discard set firewall filter block_ping term 2 then accept
With the filter in place on the private WAN link, you expect to find the critical application forwarded over the broadband Internet link.
root@Mist-SRX-GW# show services rpm probe-results owner office365_rpm_primary Owner: office365_rpm_primary, Test: office365_test_primary Target address: 40.97.223.114, Probe type: icmp-ping, Icmp-id: 93 Destination interface name: ge-0/0/3.0 Test size: 5 probes Probe results: Internal error Probe sent time: Mon Jun 7 16:49:14 2021 Probe rcvd/timeout time: Mon Jun 7 16:49:14 2021 Results over current test: Probes sent: 4, Probes received: 0, Loss percentage: 100.000000 . . . root@Mist-SRX-GW# show route table office365_RInstance office365_RInstance.inet.0: 13 destinations, 16 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/2] 00:04:30, metric2 0 > to 172.16.1.1 via ge-0/0/2.0 [Static/10] 04:08:08 > to 192.168.220.1 via ge-0/0/3.0 [Static/20] 03:45:06 > to 172.16.1.1 via ge-0/0/2.0 [Static/30] 04:08:08 > via dl0.0 10.10.20.0/24 *[Direct/0] 04:08:08 > via ge-0/0/4.20 . . .
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.
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.
user@host>show security advance-policy-based-routing statistics
Advance Profile Based Routing statistics:
Sessions Processed 1930640
App rule hit on cache hit 4540
App rule hit on HTTP Proxy/ALG 0
Midstream disabled rule hit on cache hit 0
URL cat rule hit on cache hit 0
DSCP rule hit on first packet 92693
App and DSCP hit on first packet 0
App rule hit midstream 0
Midstream disabled rule hit midstream 0
URL cat rule hit midstream 0
App and DSCP rule hit midstream 0
DSCP rule hit midstream 0
Route changed on cache hits 97233
Route changed on HTTP Proxy/ALG 0
Route changed midstream 0
Zone mismatch 0
Drop on zone mismatch 0
Next hop not found 0
Application services bypass 0
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.