Control Branch Traffic from a Main Site

Instructions to manage the performance of applications to/from multiple branches with a main-site unit

Most PacketGuide content and advice assumes you are managing the traffic moving through your local WAN or Internet link for the benefit of local users. However, frequently a large-capacity unit at a central or main site manages the traffic going to and from multiple branch offices for the benefit of each of those remote branches.

For the most part, the strategy and methods you use to manage only local traffic also apply to managing traffic from multiple branches. You still classify and organize your traffic in a traffic tree; you still analyze utilization and performance; you still protect, contain, pace, and/or provision bandwidth for your applications with all the same commands and windows. The differences center around how you organize your traffic tree and how you allocate an appropriate amount of bandwidth for each location.

When you rely on a main-site unit to manage the traffic and application performance at multiple remote sites, it's best if your WAN is a pure hub-and-spoke design, with all branch traffic going through the main-site PacketShaper. There should be no branch-to-branch traffic, as PacketWise can manage only the traffic it can see.

   Steps:

1. Create a location-based traffic tree that suits your locations' needs and main-site unit's capacities.
   

   The way your traffic tree organizes traffic dictates how it can analyze and control traffic and the features you have available. For example, if your tree doesn't distinguish traffic to your Paris office from traffic to your Oslo office, then you won't be able to compare traffic volumes or give prescribed amounts of bandwidth to each branch.

   A location-based tree analyzes and controls traffic based on the traffic's source or destination first, then, optionally, on other criteria such as application. Choose and create one of the following types of location-based traffic trees:
   
   
   • Simple location-based tree: manages only the gross bandwidth going to each location. Appropriate for occasions when your primary concern is to provision bandwidth, and you don't particularly care how it's used or how applications perform. In addition, this tree can be handy for a main site when anther PacketShaper sits at each branch location and manages application performance for that location.
   • Location-based tree with per-location applications: provides the most power and flexibility in management. Takes more time to configure and usually requires a larger product model due to the number of traffic classes required.
   • Location-based tree with global applications: manages each application with the same strategy for all locations. Most difficult tree to understand conceptually, but the easiest to configure and needs the least amount of traffic classes, matching rules, and configuration time. Provides a very scalable and easy-to-manage tree for traffic shaping but does limit visibility.
     
     
2. Define a static partition for each branch location's traffic class that corresponds to the size of the branch's WAN link. For example, if you have a branch office in Oslo (with a 512 Kbps WAN link) and a corresponding traffic class called "Oslo," then you should define a static partition of size 512 Kbps.
   
   For more information, see Partition Overview.
   
   
3. If you have:

• A simple location-based traffic tree
  You're done.
  
  
• A location-based tree with per-location applications
  Treat each branch's subtree as an application-based traffic tree, creating appropriate partitions and policies for the application classes as needed — generally, only the applications that need to be protected or contained. Look to Policy and Partition Guidelines for help in determining appropriate definitions. If you need assistance with the mechanics of creating the partitions or policies, use Create a Rate Policy, Create a Priority Policy, Create a Static Partition, Create a Dynamic Partition, and instructions for creating other types of PacketGuide policies for assistance.
  
  
• A location-based traffic tree with global applications (all branch classes followed by all application classes in your tree), continue with the remainder of this recommendation.
  

Creating Application Policies for Each Branch's Traffic to Inherit
(for location-based traffic trees with global applications)

The goal with this type of traffic tree is to manage any given traffic flow with a partition for the flow's branch location and with a policy for the flow's application. You already assigned partitions to each branch. Now you'll define policies for the application classes and make sure that each branch's traffic can inherit them.

1. Make each application class inheritable.
   
   PacketWise classifies each passing traffic flow in the class that matches the flow's branch location. It adds the metrics for the traffic flow only to the matching branch class. It applies the partition you assigned to the matching branch class.
   
   But when PacketWise finds no policy assigned to the branch class, it continues searching until it finds another matching class that is inheritable and has a policy. PacketWise finds one of your application classes as the second match. The flow inherits the second class' policy. But the second class gets no performance metrics recorded other than an additional policy hit.
   
   For more on inheritance, see Inheritance Rules.
   
   
2. For each application that needs protection and prompt performance, define a rate or priority policy with a priority of 4, 5, 6, or 7 (depending on importance and urgency). Remember that this application will use this policy no matter what branch location it's traveling to or from. For help in determining an appropriate policy for the application, see Policy/Partition Guidelines.
   
   
3. For each application that tends to use more than its fair share of bandwidth and undermine the performance of others, define a rate or priority policy with a priority of 1 or 2. For help in determining an appropriate policy for the application, see Policy/Partition Guidelines.
   
   
4. For each application that you want to block entirely, define a policy for the traffic class to block the traffic:
   
   To block UDP traffic or traffic that runs over UDP, set a discard policy on your class.
   To redirect web traffic, set a never-admit policy on your class using the web-redirect option and specify the alternate URL.
   To block web traffic without redirection, set a never-admit policy on your class using the web-refuse option.
   For non-web TCP traffic, set a never-admit policy on your class.
   
   
5. Turn on PacketWise's compression. This feature offers lossless compression of network traffic by creating compression tunnels between compression-enabled PacketShapers. No manual configuration is required, as the PacketWise application-specific plug-in architecture automatically selects the algorithm that will yield the best compression ratio for each compressible application or service type.
   
   The compression feature also allows you to define which hosts are allowed to send data through the Xpress tunnel (tunnel discovery host), or restrict the PacketShaper units that can be a tunnel partner (tunnel discovery partner).
   
   
6. After PacketWise has managed your traffic for some time, click the monitor tab. Notice that, as expected, you have traffic statistics for your branch classes, but not for your application classes. You do have class hits for your application classes. Similarly, you can create utilization reports for your branch classes, but not for your application classes.