show tree
example )The way PacketShaper organize traffic dictates how they can analyze and control that traffic. Therefore, your traffic tree configuration is a crucial choice in determining the features you have available.
For example, if your tree doesn't distinguish SAP from Oracle, then you can't measure distinct response times for each. Or, 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.
Traffic trees are very flexible. You can customize your own trees' classes using many types of criteria including application, location, protocol, host lists, addresses, ATM virtual circuits, bit markings such as MPLS or ToS, and many other strategies. We suggest a few options of tree types with their implications here. You are not limited to these trees, but you can use them in initial strategies.
Application-Based Tree
Simple Location-Based Tree
Location-Based Tree with Per-Location Applications
Location-Based Tree with Global Applications
To help in determining which traffic trees might suit your own circumstances, have the answers to these questions ready before reading the tree descriptions.
Note: You can find instructions for how to create multiple types of traffic trees in Classify Network Traffic.
This tree is for a WAN or Internet link at any main or branch site where you want to vary traffic management strategies according to type of traffic (such as application) rather than according to destination or location.
An application-based tree is most common at branch sites and main sites' Internet links. Automatic traffic discovery and classification are a good basis for the traffic classes, but you can also add or tailor classes based on other criteria. It's a simple tree to create and use.
No insight into or control over per-location behavior.
Choose a product model based on your link's capacity, anticipated maximum number of concurrent flows, and/or number of users. This configuration rarely bumps into limits on traffic classes or matching rules.
There is less growth-associated overhead than for location-based trees. Automatic traffic discovery detects many new applications and creates classes for you.
This tree is for a main site's WAN or Internet link with traffic that goes to multiple branches. It categorizes first by travel direction and then by location. It's 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. Additionally, it can be appropriate for a main site in topologies where other PacketShapers manage applications at each location, and the main site's PacketShaper just manages the amount of traffic going out to each branch.
No insight into or control over per-application behavior. No visibility into which applications travel your network.
Packeteer’s ReportCenter 3.x can collect additional information that allows you to drill-down into detailed data for the traffic flows at each defined location. With Flow Detail Records enabled on your PacketShaper, ReportCenter can collect and display data not visible from the PacketShaper alone, including the traffic's service or application, number of retransmitted bytes, Response Time Measurement (RTM) data, packet exchange time, and VoIP statistics for VoIP streams implementing the RTCP standard.
This management option scales well, as it accommodates many locations easily. Choose a product model based on your link's capacity, anticipated maximum number of concurrent flows, and number of traffic classes to accommodate your number of locations (times 2, to have each location under both Inbound and Outbound).
There is little overhead involved in adding branches, as you need only to create an additional class under both the Inbound and Outbound classes.
The most common criteria to define location-based classes are subnets or host lists. You can create initial location classes one-by-one by hand, or, if there are many classes and it gets to be a tedious task, you can automate the process with a command file and a data entry form.
At a main site, give each branch office a static partition with a size equal to the branch's WAN-link capacity. If you are concerned with each user's bandwidth, define a dynamic, per-user partition under each branch's static partition.
This tree is for a main site's WAN or Internet link with traffic that goes to multiple branches. A location-based tree with per-location applications gives you the most insight and the most control over your applications. But it imposes scaling considerations and takes more time to configure. It categorizes first by travel direction, then by location, and finally by application.
You must be prepared to manage the details of each location separately. This option requires more configuration tasks than if you had separate PacketShapers at each branch and were using PolicyCenter and ReportCenter. You must assign appropriate policies for each application you wish to manage at each location.
This style of traffic tree tends to use up many traffic classes: (number of
applications+1(for default)) * (number of branches+1) * 2(for inbound and outbound).
For example, if 15 branches each have 20 applications, 16 * 21 * 2 = 672 classes.
You would need a 6500 or higher to accommodate this tree, even if your WAN speed
doesn't require the 6500's capacity.
If you need or will shortly need more traffic classes than are available, you have outgrown a main-site-only topology. Instead, choose a distributed topology with a simple location-based tree type at your main site.
If you add a location, you add just the one class under Inbound and Outbound. Then you can use automatic discovery features (or you can copy other branches' classes).
If you add an application to some or each location, automatic discovery will probably find it. Or, you can copy a manually created class.
You must assign appropriate policies and partitions to each of an application's many classes.
At a main site, give each branch office a static partition with a size equal to the branch's WAN-link capacity. Then, under each branch, assign partitions and policies to each application that needs protection or that undermines other applications' performance. Use minimum and maximum sizes that fit appropriately under the associated branch's partition. For example, if New York has a 2 Mbps partition, then you could give SAP 500 Kbps, but not 3 Mbps.
This tree is for a main site's WAN or Internet link with traffic that goes to multiple branches. A location-based traffic tree with global applications categorizes traffic first by travel direction, then by location. That's all. The metrics, graphs, and reports are the same as those available in the simple location-only tree. The big difference is that you can define separate bandwidth-allocation policies for each application. But all traffic from one application is managed with one strategy, independent of branch.
This option is most common when all branches have the same link size and similar business priorities because each application is managed the same way for all locations. This traffic tree is the most difficult to understand conceptually, but the easiest to configure and needs the least amount of traffic classes, matching rules, and configuration time. It provides a very scalable and easily managed main-site tree for traffic shaping but does limit visibility.
This type of tree is not appropriate for a PacketShaper without the control module, as the only purpose of the application classes at the bottom is to apply policies.
No per-application insight. Must use inheritable policies in PacketShaper, one of the product's more conceptually difficult constructs.
Packeteer’s ReportCenter can collect additional information that allows you to drill-down into detailed data for the traffic flows at each defined location. With Flow Detail Records enabled on your PacketShaper, ReportCenter can collect and display data not visible from the PacketShaper alone, including the traffic's service or application, number of retransmitted bytes, Response Time Measurement (RTM) data, packet exchange time, and VoIP statistics for VoIP streams implementing the RTCP standard.
This tree scales well, as it accommodates many locations and applications easily.
The number of traffic classes this type of tree requires: ((number of branches)
+ (number of applications)) * 2 (Inbound and Outbound).
For example, if you have 20 branches and 40 applications, (20 + 40) * 2 = 120
traffic classes, well within the means of all models. You would use link speed
or another option to choose your model.
There is little overhead involved in adding branches. You need only to create an additional class under both the Inbound and Outbound classes. Automatic discovery will probably take care of adding applications. And if not, you need only to create a traffic class once for each application under both Inbound and Outbound, as the classes are not repeated under each branch.
A summary of how inheritance applies in this type of tree follows. (See Inheritance for a more complete description of inheritance and examples, if desired.)
PacketShaper classifies each passing traffic flow in the class that matches the flow's branch location. PacketShaper adds the metrics for the traffic flow only to the matching branch class. It applies any partition assigned to the matching branch class. But when PacketShaper finds no policy assigned to the branch class, it continues searching until another matching class with a policy is found.
If the tree is configured correctly, PacketShaper finds an application class 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 example, consider the following tree fragment with three branches and three
applications:
Inbound
London (Partition of 512 Kbps)
Paris (Partition of 512 Kbps)
Rome
SAP (Rate Policy 6)
WebBrowsing (Rate Policy 3)
TN3270 (Priority Policy 7)
When a 100 KB TN3270 flow heads to London, the London class gets those bytes added to its usage figures, the flow is paced to fit within London's partition, and the flow gets top access to the partition's capacity with its inherited priority 7 policy. But the TN3270 class' usage is zero because the London class was the initial classification match. The TN3270 class' policy hits does increase by one. You can generate insightful reports about the London class as a whole, but not about the TN3270 class.
At a main site, give each branch office a static partition with a size equal to the branch's WAN-link capacity. Do not assign a policy, as traffic will inherit its policy from the application classes. Then, create inheritable classes (beneath the list of locations) for each application and assign appropriate policies.
PacketGuide™ for PacketWise® 8.3