Technical Brief. Best Practice. PacketShaper and Office 365

Transcription

1 Best Practice PacketShaper and Office 365 October 13, 2016

2 Products Covered All current PacketShaper models running PacketShaper software 11.5 and above, this includes PacketShaper models PS-S200, PS-S400 and PS-S500. Solution Summary Microsoft Office365 is not a single application, it is a suite of applications, services, and protocols working together to provide a cloud based solution which enables users to work smarter, anytime, anyplace, anywhere. Some of these applications and protocols have dependencies on others, and behave differently between the Business and Personal versions. Traffic generated by Office 365 is a mixture of Latency sensitive, and large long lived aggressive flows, and where congestion is involved the latency sensitive traffic such as Voice/Video over IP typically suffers. It is worth noting that not all protocols and codecs in use are unique to Office 365, many are industry standard and used by other applications. PacketShaper is able to classify Office 365 applications and operations right out of the box. Protection, restraint, and control are policies available to the PacketShaper Administrator, to deliver Quality of Service and alignment with the customer business objectives. Some Office 365 services are classified into Office 365 classes automatically, for example: Office365_Exchange, Office365_Sharepoint, Office_Online. Other traffic such as STUN or voice/video codecs RTP-I-Dynamic_121 etc. are more generic and therefore are automatically assigned their own class. What this means is we see protocols, and codecs on the PacketShaper which are in use but these protocols and codecs are not always unique to Office 365, they have their own classification and as such show up in the Traffic Tree as their own entity (class). The challenge therefore is to easily group or relate all of these classes to Office 365 so reporting is relevant and specific. Solution Description The solution methodology to deliver quality of end user experience with Office 365 is simple. First, we identify the traffic flows to determine: Which are important to the business Which are latency sensitive Which are disruptive (i.e. using large amounts of bandwidth and are long lived) High level Process: 1. Identify the applications whose performance is crucial to your organization. 2. Identify latency sensitive traffic applications 3. Make sure you have traffic classes for each in your traffic tree. o If PacketShaper doesn't auto-discover your particular application, create a traffic class to identify the application with other criteria such as server address, port numbers, URL, etc. 4. Group together the related traffic classes (Office 365 Folder) this will allow quick and easy identification of Office 365 traffic, and specific reporting. o A script of commands to simplify this is included in the Appendix. 5. Apply a suitable partition to protect the aggregate flows for all Office 365 traffic. 6. Apply suitable policies to ensure performance on a per flow basis. o Such as Rate Control with bandwidth guarantee equal to the amount of bandwidth each Video/Voice over IP codec requires. Best Practice_PS & Office 365_v1 2

3 Understanding the Solution Partition Overview A partition manages bandwidth for aggregate flows within a traffic class, so that all of the flows for the class are controlled together as one. You can use partitions to: Protect and prioritize mission-critical traffic by guaranteeing that a traffic class always gets a defined amount of bandwidth Limit aggressive, non-critical traffic by allowing that traffic class to consume only a defined amount of bandwidth Divide capacity Assign bandwidth dynamically to users to deliver Bandwidth fair share Oversubscribe your link to harvest available excess bandwidth Protecting Traffic Partitions protect traffic by guaranteeing a defined amount of bandwidth for your mission-critical traffic classes. For example, you could set a 10Mbps partition for VoIP traffic. This partition ensures that VoIP will always have at least 10Mbps of bandwidth available. Unpredictable surges of competing traffic will not interfere with VoIP traffic. Limiting Traffic Partitions limit less important traffic by putting a cap on the amount of bandwidth a traffic class can use. For example, you can assign a 64 Kbps partition to FTP traffic in a 128Kbps link. This prevents FTP traffic from consuming your entire link and blocking more important traffic (like Oracle or Citrix). Another example of limiting traffic is restricting how much bandwidth a Class C subnet can use, regardless of how many sessions are active. You could create a 256 Kbps partition, burstable to 512 Kbps. The subnet's traffic would always get at least 256 Kbps, and could use as much as 512 Kbps if excess bandwidth is available. Dividing Capacity Some traffic, such as Voice over IP (VoIP), requires a certain amount of bandwidth in order to achieve acceptable service quality. For example, you can create a traffic class for VoIP. A partition for the VoIP traffic class manages the aggregate VoIP traffic and the concurrent flows for the class. You will then be able to combine the partition with a rate policy that defines a minimum rate for each flow. In this example, by combining a rate policy with a partition, you can ensure that VoIP always has enough bandwidth to support the multiple flows during a VoIP session. Without this reserved bandwidth, the VoIP traffic can be impacted by other more aggressive applications and the online conversation can become choppy and unintelligible, and the user experience would suffer. For more information on Partitions please see PacketGuide: Policy Overview A policy determines how an application's individual flows are treated in the context of competing applications, and allows you to manage bandwidth management on a flow-by-flow basis. With policies, you can give each mission-critical traffic flow the bandwidth it needs for optimum performance, and protect it from greedy, less important traffic. In addition, policies can keep non-urgent traffic flows (such as FTP) from consuming more than an appropriate share of bandwidth. Policy Types PacketShaper offers the following policy types: Priority Establishes a priority for traffic without specifying a particular rate. Use priority policies for non-ip traffic types, or traffic that does not burst (for example, Telnet). Best Practice_PS & Office 365_v1 3

4 Rate Smooths bursty traffic, such as HTTP, using PacketShaper TCP Rate Control technology. TCP Rate Control is an advanced congestion-avoidance mechanism whose goal is to prevent traffic from being sent at rates higher than the network connection, thereby greatly reducing queuing in router buffers and improving overall efficiency. Discard Tosses all packets for a traffic class, thereby effectively blocking the service. You might use this policy type for an application that is against company policy (such as gambling and porn) or nonessential to your business and consumes too much of your network bandwidth. Ignore Exempts a traffic class from bandwidth allocation and treats the traffic type as "pass-through" traffic. That is, the traffic won't be counted as part of the link traffic under management. Care should be taken when using this policy. If an ignore policy is placed on a class that is a major bandwidth consumer, other bandwidth allocation may be impacted. Never-Admit Restricts non-tcp traffic and intelligently rejects web and TCP traffic. Use this policy to redirect certain web users to alternate URLs. Managing Traffic For each type of traffic you want to manage, consider its behavior with respect to four characteristics: Importance Time Sensitivity Size Jitter For each characteristic below, there is an associated question to ask yourself, as well as several examples of the type of applications or protocols that fit the YES or NO answers. Importance: Is the traffic critical to organizational success? Yes, Important No, Not Important SAP to a manufacturing business Quake to a provider of gaming services Oracle to a support organization to a business YouTube or Facebook to a non-related business Games in a business context Instant messaging in a classroom Time Sensitivity: Is the traffic interactive or particularly latency sensitive? Yes, Urgent No, Not Urgent Voice or Video over IP Telnet Oracle Print File transfers Best Practice_PS & Office 365_v1 4

5 Size: Are flows large and bandwidth hungry, expanding to consume all available bandwidth? Yes, Large and Demanding No, Small Music or video streaming/downloads Telnet with large attachments ICMP Web browsing TN3270 Jitter: Does the traffic require smooth consistent delivery or it loses value, suffering stutter? Yes, Sensitive to Jitter No, Oblivious to Jitter Voice or Video over IP Flash, QuickTime or WindowsMedia Print Real Audio MS SQL Distance-learning applications TN3270 These characteristics are useful when determining what types of policies and partitions are appropriate. For example, if an application's traffic is large and demanding, a capped partition may be appropriate, independent of whether the application is important or not. Voice and Video Traffic Management Voice over IP and Video over IP can be managed with similar strategies, as both applications are latency sensitive and consist of long streaming data sessions accompanied by shorter initiation and control flows. Management recommendations for both Voice and Video over IP are described here, and are collectively referenced by the term V/VoIP. PacketShaper's recommendation for managing V/VoIP entails identifying the different types of V/VoIP traffic, reserving a portion of the network to support all of it, speeding the control traffic along quickly, giving each stream or call an appropriate amount of bandwidth, protecting individual V/VoIP users from each other, and protecting other important applications if V/VoIP demand increases. It is important to point out that though voice and video traffics both are latency-sensitive real-time, and they share similar characteristics and user requirements, they should not be managed together in the same classes with the same policies. Voice and video streams have very different bandwidth requirements, and therefore should be managed using separate traffic classes and QoS policies. Recommended Settings Office 365 Tree Grouping the Office 365 apps together in the Office 365 Class Tree simplifies the visualization, reporting and control options available to the administrator. By applying a partition to the O365 Folder class we can ensure that Office 365 apps are protected from other applications running through the same network. PacketShaper can identify and protect on a per-flow or per-call basis the latency-sensitive traffic. It is this very traffic that is most likely to experience disruption from other aggressive traffic. The types of latency-sensitive Office 365 traffic include Lync, Skype for Business, Voice and Video over IP. The PacketShaper can identify right down to the codec being used by these traffic. PacketShaper QoS control policies can then be applied on flows of these voice, video and other latency-sensitive traffic. In the example provided below, we are demonstrating a partition with a minimum guarantee of 50% of the available bandwidth (i.e. 35 Mbps) and a maximum of 90% of the circuit bandwidth. But, these values need to Best Practice_PS & Office 365_v1 5

6 be selected on a per case basis, as the customer traffic mix and available bandwidth are different. Once we have the aggregate traffic flows protected by a partition, we can now apply suitable policies to guarantee traffic flows on a per flow, or in the case of Lync V/VoIP, per call basis. Lync VoIP is using the RTP-I-Dynamic_114 codec, and the policy applied guarantees that each and every Lync VoIP call will be allocated 59Kbps of bandwidth to ensure optimum performance. Likewise, Lync Video is using the RTP-I-Dynamic_121 codec, and each call is guaranteed 383Kbps in order to ensure optimum performance. RTCP-I flows are used in setting up calls and are allocated a high priority policy of Priority 6. It is possible to allocate the RTP-I and RTCP-I traffic classes a partition of their own to protect them from other Office 365 traffic, but this level of complexity should not be required. STUN may be used by Lync or Skype or Business in some network topologies where NAT (Network Address Translation) is in use. With this in mind, a high Priority 6 policy is suggested. Other Office apps such as Exchange, Sharepoint, One Drive, etc. are allocated a Rate 3 policy to smooth or pace the flow of traffic and thereby restraining them from negatively impacting on latency sensitive traffic. Administrators may decide to apply a partition around classes such as Exchange, Sharepoint, One Drive, etc. to restrain all of their flows to a specific amount of bandwidth. They can of course still be allowed to utilize excess bandwidth when available. Best Practice_PS & Office 365_v1 6

7 Appendix Running the following cli commands will organize your O365 class tree like the example to the right. This gives quick and easy visualization of bandwidth consumption and usage by all Office 365 traffic. It allows suitable policies to be applied to protect latency sensitive traffic, and restrain large long lived flows from disrupting end user quality of experience. Please see the PacketGuide for more detail on Control Strategies at Best Practice_PS & Office 365_v1 7

8 ########################################################## # Office 365 set up commands # # by PacketShaper Pete # # packetshaperpete@bluecoat.com # # Version 1.1 # # June 23, 2016 # # copy and paste each line below into cli. # # This will create a folder called O365 and # # create Office 365 classes as children of O365 # # Visibility to the power of PacketShaper # ########################################################## class new /Inbound O365 nodefault sortorder:32000 folder class set /Inbound/O365 exception class new /Inbound/O365 RTP-I nodefault inside host:any UDP service:client outside host:any service:rtp-i class new /Inbound/O365/RTP-I RTP-I-Dynamic_114 nodefault inside host:any UDP service:client outside host:any service:rtp-i "RTP:encoding:Dynamic-114" class new /Inbound/O365/RTP-I RTP-I-Dynamic_121 nodefault inside host:any UDP service:client outside host:any service:rtp-i "RTP:encoding:Dynamic-121" class new /Inbound/O365/RTP-I Default nodefault all class new /Inbound/O365 RTCP-I nodefault inside host:any UDP service:client outside host:any service:rtcp-i class new /Inbound/O365/RTCP-I Default nodefault all class new /Inbound/O365 Office_365_Exchange nodefault inside host:any TCP service:client outside host:any service:office_365_exchange class new /Inbound/O365 Office_365_Sharepoint nodefault inside host:any TCP service:client outside host:any service:office_365_sharepoint class new /Inbound/O365 Office_Online nodefault inside host:any TCP service:client outside host:any service:office_online class new /Inbound/O365 Windows_Live_SkyDrive nodefault inside host:any TCP service:client outside host:any service:windows_live_skydrive class new /Inbound/O365 Yammer nodefault inside host:any TCP service:client outside host:any service:yammer class new /Inbound/O365 Groove nodefault inside host:any service:client outside host:any service:groove class new /Inbound/O365 Lync nodefault inside host:any service:client outside host:any service:lync class new /Inbound/O365 STUN nodefault inside host:any service:client outside host:any service:stun class new /Inbound/O365 Windows_Live_Messenger nodefault inside host:any TCP service:client outside host:any service:windows_live_messenger class rule add /Inbound/O365/Windows_Live_Messenger inside host:any TCP service:windows_live_messenger outside host:any service:client class new /Inbound Lync_Online nodefault inside host:any TCP service:client outside host:any service:lync_online class rule add /Inbound/Lync_Online inside host:any TCP service:lync_online outside host:any service:client class new /Outbound O365 nodefault sortorder:32000 folder class set /Outbound/O365 exception class new /Outbound/O365 RTP-I nodefault inside host:any UDP service:client outside host:any service:rtp-i class new /Outbound/O365/RTP-I RTP-I-Dynamic_114 nodefault inside host:any UDP service:client outside host:any service:rtp-i "RTP:encoding:Dynamic-114" class new /Outbound/O365/RTP-I RTP-I-Dynamic_121 nodefault inside host:any UDP service:client outside host:any service:rtp-i "RTP:encoding:Dynamic-121" class new /Outbound/O365/RTP-I Default nodefault all class new /Outbound/O365 RTCP-I nodefault inside host:any UDP service:client outside host:any service:rtcp-i class new /Outbound/O365/RTCP-I Default nodefault all class new /Outbound/O365 Office_365_Exchange nodefault inside host:any TCP service:client outside host:any service:office_365_exchange class new /Outbound/O365 Office_365_Sharepoint nodefault inside host:any TCP service:client outside host:any service:office_365_sharepoint class new /Outbound/O365 Office_Online nodefault inside host:any TCP service:client outside host:any service:office_online class new /Outbound/O365 Windows_Live_SkyDrive nodefault inside host:any TCP service:client outside host:any service:windows_live_skydrive class new /Outbound/O365 Yammer nodefault inside host:any TCP service:client outside host:any service:yammer class new /Outbound/O365 Groove nodefault inside host:any service:client outside host:any service:groove class new /Outbound/O365 Lync nodefault inside host:any service:client outside host:any service:lync class new /Outbound/O365 STUN nodefault inside host:any service:client outside host:any service:stun class new /Outbound/O365 Windows_Live_Messenger nodefault inside host:any TCP service:client outside host:any service:windows_live_messenger class rule add /Outbound/O365/Windows_Live_Messenger inside host:any TCP service:windows_live_messenger outside host:any service:client class new /Outbound Lync_Online nodefault inside host:any TCP service:client outside host:any service:lync_online class rule add /Outbound/Lync_Online inside host:any TCP service:lync_online outside host:any service:client 2016 Blue Coat Systems, Inc. All rights reserved. Blue Coat, the Blue Coat logos, ProxySG, PacketShaper, CacheFlow, IntelligenceCenter, CacheOS, CachePulse, Crossbeam, K9, the K9 logo, DRTR, MACH5, PacketWise, PolicyCenter, ProxyAV, ProxyClient, SGOS, WebPulse, Solera Networks, the Solera Networks logos, DeepSee, See Everything. Know Everything., Security Empowers Business, and BlueTouch are registered trademarks or trademarks of Blue Coat Systems, Inc. or its affiliates in the U.S. and certain other countries. This list may not be complete, and the absence of a trademark from this list does not mean it is not a trademark of Blue Coat or that Blue Coat has stopped using the trademark. All other trademarks mentioned in this document owned by third parties are the property of their respective owners. This document is for informational purposes only. Blue Coat makes no warranties, express, implied, or statutory, as to the information in this document. Best Practice_PS & Office 365_v1 8