Inheritance Rules

A traffic class inherits another class' policy if it has no policy of its own.

For each passing traffic flow, PacketWise traverses the traffic tree looking for a matching traffic class. When found, PacketWise adjusts the metrics (such as class hits) for the class and applies any associated partition and policies. If the class has no associated policy, PacketWise continues searching until another matching class is found that does have a policy. The traffic flow inherits the second class' policy. But the second class gets no performance metrics recorded other than an additional policy hit.

PacketWise searches classes in a particular order as it looks for a qualifying inheritable class. It searches down the traffic tree, first examining the original class' successive siblings, then the parent's siblings, then the grandparent's siblings, and so on, until a qualifying class is found.

PacketWise searches for a class with four characteristics:

Its matching rules encompass the original traffic.
It has an associated policy.
It is an inheritable class (that is to say, it has an inheritable policy).
It is the first such class encountered in PacketWise's prescribed search order.

For example, given this traffic tree fragment:

- Inbound
  - SAP (with a rate policy)
  - Citrix (with a partition)
     - PeopleSoft over Citrix (no policy)
     - MS Word over Citrix (inheritable class with a rate policy)
     - Default (inheritable class with a rate policy)
  - SMTP (no policy)
  - Default (inheritable class with a priority policy)

/Inbound/Citrix/PeopleSoft traffic does not inherit /Inbound/Citrix/MS Word's policy because Word's matching rule conflicts with PeopleSoft's. The /Inbound/Citrix/PeopleSoft traffic does inherit /Inbound/Citrix/Default's rate policy. If /Inbound/Citrix/Default were not an inheritable class, then /Inbound/Citrix/PeopleSoft would inherit /Inbound/Default's policy. /Inbound/SMTP traffic inherits /Inbound/Default's priority policy.

Note: Classes that have an inheritable policy have boldfaced names in the traffic tree (as shown in the example above).

In another example, consider the following fragment of a location-based traffic tree with three branch offices 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.

To designate a class as inheritable — that is, you want other classes to be able to inherit its policy — you can either:

In the manage tab of the browser interface, select the Inheritable button for the class. Note that the class must have a policy before you can see the button. See Create an Inheritable Traffic Class.
In the command-line interface, use the class set <tclass> inherit command.

Typically, the default classes such as /Inbound/Default show more policy hits than class hits. That's because the policy hits for the /Inbound/Default class include policy hits for classes without policies that appear earlier in the subtree.

If a class (A) didn't have its own policy and was inheriting a policy from another class (B), and then you assign class A its own policy, there are several policy-related characteristics that will be copied from class B's policy: DiffServ/TOS substitution, MPLS labels, delay bound, and flow limit. For example, suppose Inbound/Test was inheriting the Inbound/Default policy (Priority 3, flow limit of 10,000 client and 100,000 server flows per minute) and then you assign Inbound/Test its own policy (a Rate policy). The Inbound/Default class' flow limit policy will be copied to the Inbound/Test class. Thus, Inbound/Test will have a rate policy in addition to a flow limit policy of 10,000 client and 100,000 server flows per minute.

PacketGuide™ for PacketWise® 8.1