LiveNX vs. Hardware Probes

Microsoft© Skype© for Business, is an enterprise-level collaboration solution for instant messaging, presence, conferencing, file sharing, and telephony. While Skype is a simple application to use, protecting Skype voice and video call quality can be difficult.

Fortunately, a network administrator can effectively implement Quality of Service (QoS) protection for Skype using LiveAction’s application-aware network performance management solution, LiveNX.

This document describes how to protect critical Skype audio and video traffic throughout the network with LiveNX. Learn how to:

• Configure Skype audio and media ports and markings at the Clients and Server
• Use LiveNX to verify Skype traffic through the network
• Use LiveNX to create Access Control Lists (ACLs) for Skype
• Use LiveNX to configure QoS Marking Policy
• Use LiveNX to configure QoS Queuing Policy
• Use LiveNX to monitor performance of Skype

By using NBAR2 (protocol pack 12 or higher), Cisco’s application recognition technology built into IOS, Skype QoS management can be simplified to identify Skype audio and video without having to configure Microsoft Skype Servers for QoS, Microsoft Group Policies for QoS, or build and manage complex ACLs in the network infrastructure.*

This can translate to 50% faster (or higher) QoS deployments and reduces the chance of mistakes during configuration.

Microsoft Skype is an application that allows enterprise users to communicate via chat, presence, audio/video conferencing, IP telephony, and collaboration tools. Communication occurs between users that have installed the Skype software on their PC, MAC or mobile devices. The enablement of these communication technologies is dependent on several Skype servers. Each server has a specific role in the Skype operation. The roles can be colocated on one server or installed on multiple servers to add high availability and scaling capabilities. These roles are:

• Front-End Servers
• Back-End Servers
• Mediation Servers
• Edge Servers

By default, Skype clients and servers do not set QoS markings on their data. Skype client-to-client communication does not use a defined range of TCP/UDP ports. Since the network infrastructure cannot recognize Skype traffic by port or QoS marking in its default state, it cannot prioritize these flows as they traverse the network.*

This can cause performance impact to both Skype voice and video traffic on highly utilized enterprise networks.

To ensure Skype always receives the QoS priority it needs, it must be configured to set QoS markings on its traffic as it is sent onto the network. Microsoft has published white papers on their website for enabling QoS on Skype traffic.

These documents can be summarized into two steps:

1. Set uniform TCP/UDP port ranges that Skype applications will utilize
2. Set QoS markings on Skype clients and servers based on the port ranges above

This means that network administrators must configure the appropriate QoS markings by application (VOIP, VIDEO, etc.) for each client and server that participates in a Skype solution. There are three types of Skype communications: client-to-client, client-to-server, and server-to-server.

Each application must be configured for these communications scenarios. Fortunately,

centrally configured shell commands and Microsoft Group Policy can manage these configurations. Once the Skype clients and servers have been configured to set the appropriate QoS markings for Skype data, the network infrastructure that these applications traverse must also be configured to support the level of call quality required to meet business objectives.

This is done by the configuration of IP QoS to all applicable network devices (routers and switches) that transmit and receive Skype voice and video. The management and configuration of QoS in networks can require reviewing hundreds of lines of Command Line Interface (CLI) commands to understand the configuration and performance of QoS policies on just one device alone. LiveNX has been designed to streamline the implementation and management of QoS in network environments and can be used to easily deploy this complex set of technologies to the network infrastructure.

*Cisco has updated its NBAR2 application recognition technology to granularity recognize Skype audio and video. By using NBAR2 protocol pack 15 (or higher) on the application Cisco routers and LiveNX, it is possible to easily protect Skype audio and video via just the network infrastructure. This means it is possible to eliminate the need for any changes on Microsoft servers or clients as outlined in this document (see Appendix D for further details).

This document provides configuration parameters required to configure Skype for Business clients and servers. It also details the steps of implementing, monitoring, and validating QoS in a network infrastructure using LiveNX.

Microsoft Skype QoS Design

The following diagram shows a typical Skype enterprise deployment.

Define TCP/UDP Port Ranges

The first step in deploying QoS for Skype is to define the TCP and UDP port numbers that the Skype applications will use. These port numbers should be configured in a consistent way so all devices that participate in Skype will use the same ports for each application type–for example, VOIP could always use ports 20000-2099, video 21000-21099, etc.

Client-to-Client Settings

To configure client-to-client port use, you can use the following shell commands on the Skype Front-End Server. Once these parameters have been set, Skype clients should log off and back on for the new settings to take. The following commands are a valid example of how to configure these settings:

Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled $True

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 100

Set-CsConferencingConfiguration -ClientVideoPort 20100 -ClientVideoPortRange 100

Set-CsConferencingConfiguration -ClientAppSharingPort 20200 -ClientAppSharingPortRange 100

Set-CsConferencingConfiguration -ClientFileTransferPort 20300 -ClientFileTransferPortRange 100

These can be entered via: Start > All Programs > Microsoft Skype Server 2016 > Skype Server Management Shell

Microsoft Skype Phone Edition Settings

The default QoS DSCP value of Skype Phone Edition is 40. In most environments, the DSCP value for audio traffic is 46. To update this configuration, issue the following command:

Set-CsUCPhoneConfiguration -VoiceDiffServTag 46

This can be entered via: Start > All Programs > Microsoft Skype Server 2016 > Skype Server Management Shell

Microsoft Skype Server Settings

To configure client-to-server and server-to-server port use, you could use the following shell commands on the Skype Frontend Server. These settings update the Skype Conference, Application, and Mediation servers. Once these parameters have been set, the appropriate Skype services will need to be restarted to apply these new settings. The following commands are a valid example of how to configure these settings:

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -AudioPortStart 21000 -AudioPortCount 1000

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -VideoPortStart 22000 -VideoPortCount 1000

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -AppSharingPortStart 23000 -AppSharingPortCount 1000

Set-CsApplicationServer -Identity <ApplicationServer:FQDN of Skype Application Srv. Pool> -AudioPortStart 21000 -AudioPortCount 1000

Set-CsMediationServer -Identity <MediationServer:FQDN of Skype Mediation Srv. Pool> -AudioPortStart 21000 -AudioCount 1000

These can be entered via: Start > All Programs > Microsoft Skype Server 2016 > Skype Server Management Shell

Microsoft Skype Server Settings

To configure client-to-server and server-to-server port use, you could use the following shell commands on the Skype Frontend Server. These settings update the Skype Conference, Application, and Mediation servers. Once these parameters have been set, the appropriate Skype services will need to be restarted to apply these new settings. The following commands are a valid example of how to configure these settings:

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -AudioPortStart 21000 -AudioPortCount 1000

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -VideoPortStart 22000 -VideoPortCount 1000

Set-CsConferenceServer -Identity <ConferenceServer:FQDN of Skype Pool> -AppSharingPortStart 23000 -AppSharingPortCount 1000

Set-CsApplicationServer -Identity <ApplicationServer:FQDN of Skype Application Srv. Pool> -AudioPortStart 21000 -AudioPortCount 1000

Set-CsMediationServer -Identity <MediationServer:FQDN of Skype Mediation Srv. Pool> -AudioPortStart 21000 -AudioCount 1000

These can be entered via: Start > All Programs > Microsoft Skype Server 2016 > Skype Server Management Shell.

The Skype Edge servers do not need to reconfigure ports because they rely on the other Skype devices inside the network for port selection. Note that DSCP markings only need to be set for private Skype traffic. Any DSCP values marked on Skype traffic will typically have these priority settings ignored by all service providers.

Define Group Polices

Once the Skype port settings have been assigned to all applicable device types via the Skype Server Management Shell, DSCP markings can be set by implementing Group Policies for these applications’ port ranges. To implement a QoS Group Policy, navigate to a computer with Group Policy Management installed, locate the container where the new policy

should reside (e.g., client OU), right-click on the container, and select “Create GPO in this domain, and link it here.” The following screenshots will display how to configure the appropriate Group Policy for Skype Audio. This is applicable for Windows 7, 8, and Vista clients.

First, name the policy and specify the DSCP value.

Define the application to which this policy applies.

Specify the source and the destination address to which this policy applies.

Select the protocol and port ranges that this policy matches with and click “Finish.”

Microsoft Skype DSCP Marking Group Policies

The same process will need to be repeated for all other Skype clients and servers (Conferencing, Mediation, Application). Please use the table below as a sample reference for defining Skype TCP/UDP ports and Group Policies. The port numbers used in this example would be valid for an environment with up to 500 simultaneous conference users.

Note: These ranges may not be appropriate for all network designs.

Microsoft Skype relies on the network infrastructure to honor and queue its traffic for call quality protection. The following pages will describe the steps to implement and validate these QoS policies in a network infrastructure using LiveNX.

How Does QoS Work?

Quality of Service (QoS) manages bandwidth usage across different applications and technologies. Its most common use is to protect real-time data applications like video or VoIP traffic. All network infrastructure devices have limits on the amount of traffic flowing through them. In packet and frame switched networks, data is delayed or dropped during times of congestion. Quality of Service (QoS) management is the collection of mechanisms that control how traffic is prioritized and handled during these times.

The two most common QoS tools used to handle traffic are classification and queuing. Classification identifies and marks traffic to ensure network devices prioritize data as it crosses the network. Queues are buffers in devices that hold data to be processed. Queues provide bandwidth reservation and prioritization of traffic as it enters or leaves a network device. If the queues are not emptied (due to higher priority traffic going first), they can overflow and drop traffic.

Policing and shaping are also commonly used QoS technologies that limit the bandwidth used by predefined traffic types. Policing enforces bandwidth to a specified limit. If applications try to use more bandwidth than allocated, their traffic will be dropped. Shaping defines a software set limit on the transmission bandwidth rate of a data class. If more traffic needs to be sent than the shaped limit allows, the excess will be buffered. This buffer can then utilize queuing to prioritize data as it leaves the buffer.

The WRED (Weighted Random Early Discard) technology provides a congestion avoidance mechanism that will drop lower-priority TCP data to protect higher-priority data from being dropped.

Link-specific fragmentation and compression tools are used on lower bandwidth WANs to ensure real-time applications do not suffer from high jitter and delay.

Table 1: Packet flow through a typical QoS policy

LiveNX is an application-aware network performance management tool that will graphically display how networks and applications are performing using SNMP and the latest advanced NetFlow capabilities now embedded in Cisco devices. LiveNX can control application performance via its graphical QoS management capabilities. With LiveNX, QoS can be configured to manage and control Skype audio and video traffic.

This document will describe how LiveNX can be used to confirm the application performance of Skype using the latest Performance Monitoring technology now available in Cisco devices. The image below is a view of the LiveNX console. It shows a network diagram consisting of two Skype clients and three network devices. The three larger green circles represent routers and switches managed by LiveNX. The little green circles within the devices represent their interfaces.

Microsoft Skype Audio QoS Classification with LiveNX

Since LiveNX is also a NetFlow collector, it visualizes the traffic flowing over the network.

The light blue arrows represent Skype audio traffic traversing the network in the diagram below. In this example, the color legend below shows that the light blue arrows represent Best Effort traffic. This is what one would expect to see before any QoS configuration is implemented on the Skype servers and clients.

Double-clicking on any larger circles (routers/switches) in the LiveNX network diagram will show the real-time NetFlow data of traffic flowing through the device. In the example below, the Skype traffic’s UDP port numbers are not in the administrator’s defined port ranges, and the DSCP values are Best Effort. This confirms that the Skype servers and clients have not yet been configured appropriately for QoS.

After the appropriate Skype QoS settings have been implemented on the Skype servers and clients, the network diagram will show red arrows, in addition to the light blue arrows. This indicates EF or high priority markings are now being set on Skype audio traffic. But notice in the example below that the red arrows are not being drawn through the whole Skype conversation path. This indicates that the network infrastructure’s QoS trust policy is not configured correctly.

This can be confirmed by double-clicking on the device, showing the red arrows painted through it. In the LiveNX real-time NetFlow view below, the UDP ports are in the appropriate range, and the DSCP value is EF.

If, instead, you double-clicked on one of the devices showing just blue arrows, the UDP ports would be in the appropriate ranges, but the DSCP value would still be 0.

The previous screenshots validate what the LiveNX network diagram indicated; the DSCP value of 46(EF) is being lost by some type of misconfigured QoS trust policy in the network. To investigate this network QoS issue further, the administrator should start the troubleshooting process on the last device that shows the intended QoS markings. In this example, this would be the first device on the left with the red arrows passing through it (shown below). Fortunately, the LiveNX application doesn’t stop at just showing the Skype QoS problems but gives administrators the ability to fix the QoS issue with its graphical QoS management tools.

To access these tools, click the “QoS” tab at the top left of the LiveNX network diagram and double-click on the device that needs QoS configuration investigation (the device to the left in this example).

This will show a list of interfaces managed on this device. Notice in the screenshot below that on the Ethernet 0/0 interface, there is a QoS policy named “SET_DSCP” configured in the input direction.

To further investigate this policy, right-click on the policy’s name > select QoS > Manage QoS Settings.

This will bring up a new window (shown below) that will allow the administrator to configure all required QoS policy settings via LiveNX’s GUI. Select the policy named “SET_DSCP” in the list to the left. This will show a list of the classes applied to this policy. In this example, there is only one class named class-default. Click on “class-default” to highlight it. Notice how this policy is currently marking all traffic (via the class-default) with a DSCP value of 0, Best Effort.

This policy needs to be fixed to allow Skype traffic’s DSCP markings to pass through this device unchanged— that is, the DSCP value of 46 will be seen across all infrastructure devices to ensure consistent QoS handling of Skype traffic across the network. To do this, first right-click on the “SET_DSCP” policy and select “Add Class to Policy.” This will bring up a new window. Create a new class called “SKYPE_AUDIO.”

The new class will be added to the SET_DSCP policy. Match criteria need to be defined to ensure the correct traffic uses this class. Click the “Edit” button on the “Classify Tab.”

This will bring up the “Create and Edit Match Statements” configuration page. Select “DSCP” from the “Match Type” dropdown.

Select a “Value” of “46(EF)” and click “Add Match Statement.”

The DSCP value will now appear in the far-right column, indicating it is a correct match type for this class. Click “Save to Device.”

Click on the “Policies” tab to the top left of the screen to review the changes made to the SET_DSCP policy. Notice DSCP value 46(EF) is now a match type of the SKYPE_AUDIO class. This would fix this QoS issue. But what if this network has other VOIP traffic marked EF too?

It would also match this class intended for Skype audio traffic. Since this is a classification and marking policy at the network edge, it would be best to ensure that only Skype audio matches this class. To enforce this, a second match type needs to be added to this class, and the class needs to use the “Match All” setting (to use AND logic). To make these changes, click the “Edit” button.

Select Match Type “ACL Name.”

Select an access list that matches the UDP ports used for Skype client and server audio. There is already an access list available in the example shown below called “SKYPE_AUDIO_ACL.” Select this access list and click “Add Match Statement.” See Appendix A for more information on creating and managing access lists using LiveNX.

Select “Match All” from the drop-down at the top center of the screen. Click “Save To Device.”

Click on the “Policies” tab to validate both match criteria, and the “Match on All” is configured correctly. If everything is valid, “Close.”

Click “Home” in the device list to the left to return to the network diagram view. Click the “Flow” tab and click the “Refresh” button. If the previous example is the only network QoS issue, all arrows will show red for this Skype conversation. This means that all devices see Skype traffic marked with a DSCP value of 46(EF), a high priority.

These QoS settings can be confirmed by double-clicking on any devices that show red arrows running through them. In the LiveNX real-time NetFlow view below, the UDP ports are in the appropriate range, and the DSCP value is EF.

Note that this QoS classifying and marking example is simple. The steps shown need to be repeated throughout the network environment to ensure all Skype client and server audio DSCP markings are honored appropriately.

Microsoft Skype Audio QoS Queuing with LiveNX

Once Skype audio traffic has been classified and honored as high priority (DSCP 46(EF)) end-to-end in the network, steps should be taken to ensure Skype traffic is prioritized appropriately. The diagram below shows Skype traffic being marked properly (as red) end-to-end.

This prioritization needs to happen at any congestion point in the network. Congestion occurs most often at the WAN edge but can also happen in the LAN. When implementing a QoS queuing policy, start where the problem occurs most, the WAN edge. The following pages will show how to configure a queuing policy using LiveNX to prioritize Skype traffic at the WAN edge.

First, click the “QoS” tab and double-click the middle device (in this example, the data center WAN edge device).

This brings up a list of the interfaces on this device. In this example, there are no QoS policies applied to any interface. To create a queuing policy, right-click on an interface and go to QoS > Manage QoS Settings.

This brings up the Manage QoS Settings window, as seen below. To create a new policy, click the “Add Policy Button” at the top left of the page.

In this example, the new policy will be named QUEUEING.

Right-click on the policy and add a new class to the policy. This new class will be called VOIP.

 

Add match criteria as described above to match EF to the VOIP class.

Click the queuing tab and select the queuing type “Priority.” Set the bandwidth percentage to 33%. This is a safe starting number for this queue and can be adjusted by monitoring the queue’s performance over time. See below for examples of how to monitor this queue.

Click on the “Interface” tab, right-click on the output of interface Ethernet 0/2 (the WAN interface) and apply the QUEUING policy.

Click “Save to Device” and “Close.” Skype audio traffic will now be given priority when this WAN interface becomes congested.

To verify Skype’s performance, return to the network diagram. Click the “Home” icon at the top left of the screen, select the “QoS” tab, and double-click on the Ethernet 0/2 interface. The graph and legend to the bottom of the screen show the real-time performance statistics of this new QoS policy. This screenshot confirms that the VOIP queue protects 46(EF) traffic (Skype in this example).

To see this same information historically, click the “1hr” button to the top of the screen to run a historical report for this policy’s performance. Click the “Custom” button to view this policy for an administratively defined time range. In the historical information below, notice how the “Post-Policy Report” shows traffic in the VOIP queue (Skype in this example) at 210kbps. This matches with the real-time report above.

Another QoS historical report useful for monitoring QoS performance is the “Pre-Policy and Post-Policy Drops” Report. The “Class drops” graph and legend will show which queues have dropped traffic. In this example, there are no drops in the VOIP queue. This validates that Skype traffic performs optimally on this interface for the time range shown.

Microsoft Skype Video QoS with LiveNX

The steps to configure and confirm Skype video application performance are very similar to the steps shown for Skype audio. The task required will be summarized below. First, ensure Skype video is classified and matched appropriately. This would include ensuring Skype video traffic is trusted as it enters the network edge. Using the example from the Skype audio section of this document, add a “SKYPE_VIDEO” class to the SET_DSCP policy. Using “Match on ALL” for both the DSCP value and ACL is recommended to ensure only Skype traffic matches this class.

 

Once the appropriate trust configuration is in place, LiveNX will validate that the DSCP value is marked end-to-end by showing the colored arrows across the network map. The red arrows indicate Skype audio (EF) in the example below, and the gold arrows indicate Skype video (AF41).

Once DSCP markings are confirmed to be honored through the network end-to-end, Skype video should be prioritized on the appropriate network devices. Using LiveNX’s QoS tools, create a new video class on the same queuing policy for Skype audio. Configure the class to match on DSCP 34(AF41).

Configure this VIDEO class to queue traffic. In this example, the video class will be assigned 20% as a CBWFQ.

Once the video queue is created, its operation can be confirmed by viewing the interface’s QoS statistics. In the example below, video traffic is being matched in the bottom graph in purple.

LiveNX has ACL management capabilities that allow administrators to configure and push access lists to the enterprise. This gives engineers the ability to manage and deploy ACL in their network centrally. To address the access list on a device, right-click on the device, select “Device Tools,” and “Manage ACLs.”

A list of the ACLs found on the device will appear. Click on one of the access lists to see its configuration at the bottom of the screen. Click the “Edit ACL” button to manage the access list. The example ACL below shows the information that would match Skype Audio in this document.

Select one of the ACL rules and click “Edit Rule” to update the variables as appropriate.

Edit the ACL as required and click “OK” when finished.

The ACL referenced above can be used as the match criteria for a QoS policy (as shown below).

Below is another example of ACL. This example shows the information that would match the Skype video in this document.

LiveNX supports the Cisco Performance Monitoring Flexible NetFlow template. Administrators can deploy and manage Performance Monitoring in the network infrastructure and gather application performance metrics (packet loss, jitter) for voice and video over IP. LiveNX gives administrators the ability to understand how these applications perform without probes or other costly network appliances. Using the technology now embedded inside Cisco network equipment, voice and video call quality issues can be detected and reported to network administrators before end-users ever complain. The first step in gaining this visibility into voice and video application performance is to enable this flow type in the Cisco network infrastructure. LiveNX can automate these tasks and allow this complex set of configurations in a simple point-and-click manner. This can be done with the following step: From the Menu bar, Select Flow > Configure Flow.

Check the devices to enable the Voice/Video Performance (Medianet) flow type and click “Configure Selected.” In this example, all three devices are checked.

Check the box of the desired technology on each interface and click “Save to Devices.” All interfaces have FNF (basic Flexible NetFlow) and Voice/Video Performance (Medianet) selected in this example.

Once the Performance Monitoring flow type is enabled, navigate to a device’s real-time NetFlow view by clicking the “Flow” tab and then double-clicking on a device in the network map. Select the flow type drop-down menu and select “Medianet.”

The real-time Performance Monitoring flow records will now appear. Packet loss and jitter measurements will now be visible in the flow record. In the example below, two of the flows are highlighted in pink due to an alarm being triggered by the cells in red. These flows Jitter Max measurements triggered an alarm. Network administrators can receive performance alerts via email or Syslog message.

LiveNX and NBAR2 make protecting Skype traffic easy. Earlier in this guide, methods were described on recognizing and marking ingress traffic using ACLs to identify ports used for Skype audio or video. This required changes to the Microsoft servers and clients. The NBAR2 protocol pack 12 (or higher) is no longer necessary. NBAR2 applications can be applied directly to QoS policies using the LiveNX QoS Management GUI.

Begin by creating an ingress to QoS Policy to Classify Skype Audio as DSCP 46. To do this, open the LiveNX Manage QoS Settings window.

Create a new QoS Policy by selecting “Add Policy” and giving the policy a name.

After creating the new policy, right-click on the new policy and select “Add Class to Policy.”

Give the new class a name.

Next, select “Edit” to add Skype audio to the class.

Select “Protocol–using NBAR” as the match type on the Class Tab. Then select “ms-lync-audio” as the NBAR application, and then select “Add Match Statement.”

Now, go back to the Policies tab and select the Marking tab. On the Marking tab, check the box for DSCP and select “46 (EF).”

Now add another “class” to the SET_DSCP policy to mark our Skype video traffic as DSCP 34.

After creating the new class, select “Edit.”

Once on the class tab, select the match type to be “Protocol–using NBAR” and then select “ms-lync-video” and lastly, “Add Match Statement.”

Go back to the “Policies Tab” and select the “Marking Tab” to properly mark Skype video as DSCP 34.

Apply the new policy to an interface by right-clicking on the policy and selecting “Apply Policy to Interface.”

Select the interface to apply the policy to and select “OK.”

Lastly, select “Save to Device” to apply the policy to the device itself.

Now that Skype audio and video were quickly identified and marked in the SET_DSCP Policy create a queuing policy to protect the traffic.

Create a new policy from the “Manage QoS Settings” on the device that needs a queuing policy

Call the new policy “queuing.”

Right-click on the new “queuing” policy and select “Add Class to Policy.”

Give the new class a name.

After the new policy is created, select “Edit” to match the DSCP 46 markings.

On the “Classes Tab,” select “DSCP” as the “Match Type.” Select “46 (EF)” as the value, and then “Add Match Statement” to those markings.

After selecting the correct match type, return to the “Policies Tab” and select the “Queuing Tab” for the VOIP Class. Set the priority bandwidth percentage to 33%. This is a safe starting number for this queue and can be adjusted by monitoring the queue performance over time.

Create a second video class to the policy to protect Skype video.

Select “Edit” to correctly classify video traffic DSCP 34.

On the classes tab, please select “DSCP” as the match type, “34 (AF41)” as the value, then select “Add Match Statement.”

 

After selecting the correct match type, select the “Policies Tab” and select the “Queuing Tab” for the video class. Set the bandwidth percentage to 20%. This is a safe starting number for this queue and can be adjusted by monitoring the queue performance over time.

 

The queuing policy can now be applied to an interface.

 

Add the policy to the correct interface.

 

“Save the policy” when completed.