The Exinda policy tree

All network behavior that you want to modify by using the Exinda Appliance is specified by policies in the optimizer. This includes traffic shaping, prioritization, acceleration, and packet marking. These policies are arranged hierarchically in a tree so that you can assign different policy rules to different types of traffic on your network. The hierarchy consists of circuits, virtual circuits, and policies.

Role of circuits, virtual circuits, and policies

The policy tree is arranged as a three-level hierarchy. The top level of the hierarchy consists of circuits that partition the traffic by bridge. The second level of the hierarchy consists of virtual circuits that logically partitions each circuit. The third level of the hierarchy consists of policies that define which actions to take on the traffic.

Circuits relate to physical connections to the Exinda Appliance. For appliances with more than one bridge configured, you can create a separate circuit for each bridge or you can treat all bridges as one combined circuit. Typically, one circuit would be created for each physical link.

A circuit can contain one or more virtual circuits for the purpose of partitioning the traffic that falls in that circuit. The virtual circuitlogical definitions that partition a a physical network circuit and used to determine what traffic passes through it and how much defines what traffic will be processed in this partition and how much bandwidth it is allowed. Each virtual circuit will have it's own set of policy rules. The following are common use cases for virtual circuits.

• A circuit needs to be partitioned into traffic destined for a remote office versus traffic destined for the Internet.
• A circuit needs to be partitioned into traffic destined for particular branch offices.
• You are a service provider and your circuit needs to be partitioned into traffic destined for each of your customers.
• You have an asymmetric circuit and you want to control absolute bandwidth limits (e.g. To guarantee 100 kbps for VoIP traffic inbound and outbound).
• You want to control and monitor different subnets in your network (e.g. One virtual circuit to control and monitor your wifi network, and another to control and monitor your servers, and another to control and monitor your back-office computers.)
• You want to enforce fair sharing amongst the network hosts in the virtual circuit.
• You want a certain number of hosts or connections to get preferential treatment such as having access to a high-bandwidth virtual circuit.

Each virtual circuit contains a set of policies that define what actions to perform on each type of traffic. Policies can shape the traffic by throttling traffic, blocking traffic, or prioritizing important traffic higher than unimportant traffic. Policies can also accelerate the traffic by using acceleration techniques or caching techniques. Policies can also merely monitor the traffic. The following are common uses for policies.

• Policies to throttle or block non-critical traffic, such as P2P traffic.
• Policies to protect business-critical traffic, such as Mail or Database traffic.
• Policies to protect and prioritize business-critical latency sensitive traffic, such as voice traffic.
• Policies to throttle a particular user or host, such as throttling John's access to streaming videos.
• Policies to protect a particular subnet, such as a server or set of servers.

Circuits, virtual circuits, and policies can be managed by selecting various options from the drop-down to the right of the respective item.

To learn more about circuits, virtual circuits, or policies, see Circuits, Virtual Circuits, and Policies.

How traffic is evaluated against the policy tree

Traffic is evaluated against the hierarchical policy tree in a top-down manner. That is, the traffic is evaluated against the circuits in top-down order to determine which circuit will be handling the traffic. Once the appropriate circuit is determined, the traffic is evaluated against that circuit's virtual circuits in top-down order to determine which virtual circuit will be handling the traffic. Once the appropriate virtual circuit is determined, the traffic is evaluated against that virtual circuit's policies in top-down order to determine which policy will be handling the traffic. Any given packet will only be handled by one circuit, one virtual circuit, and one policy.

The policy tree

When traffic is not caught by the policy tree

There are Auto-Catch All circuits, Auto-Catch All virtual circuits and Auto-Catch All policies for any traffic that does not get caught by your configured circuits, virtual circuits, and policies. Auto-Catch All do not have any policies applied to it, but they are monitored and will be shown on the virtual circuit graph.

Consider a configuration where you have two bridges on the appliance. If you define a circuit for the first bridge but not the second, then any traffic that comes in on the second bridge will fall into the Auto Catch-All circuit and will not have any of your policies applied to it.

Similarly consider a configuration where you have a circuit that will capture traffic for your entire office. You define multiple virtual circuits for each subnet that you are interested in, but your virtual circuits do not cover your entire office. For example, you have virtual circuits for your WiFi network, your servers, your staff desktop network, but perhaps you forgot your printers. The system will automatically define a virtual circuit for the remaining traffic called Auto Catch-all. Any traffic that falls into a circuit, but not into any of the circuit's virtual circuits, will fall into the Auto Catch-all virtual circuit and will not have any of your policies applied to it.

Finally consider a configuration where you have a virtual circuit that captures all the traffic for a particular virtual circuit, such as your WiFi network. You define policies for each type of traffic that you want to control or protect or accelerate, but do not include all the traffic on your WiFi network. For example, you have policies for P2P, streaming, and web, but you do not have policies for software updates. The system will automatically define a policy for the remaining traffic called Auto Catch-all. Any traffic that falls into a virtual circuit, but not into any of policies, will fall into the Auto Catch-all policy and will not have any of your policies applied to it.

Consider the opposite scenario where you have more than one circuit that could capture the same traffic. For example, you have two circuits that could both capture br10 traffic. The traffic will be evaluated against the virtual circuits and policies within the first circuit. If the traffic does not match any virtual circuits and policies in the first circuit, then it will attempt to match the traffic to the virtual circuits and policies in the second circuit. If the traffic does not match any of the virtual circuits and policies in any of the matching circuits, then the traffic will fall into the Auto Catch-All virtual circuit and Auto Catch-All policy in the last matching circuit and will not have any of your policies applied to it.

If traffic is not caught by a circuit or by a virtual circuit or by a policy, it will show up in the real-time monitor as an Auto Catch-all circuit and an Auto Catch-all virtual circuit and an Auto Catch-all policy. The Auto Catch-all circuits and virtual circuits will also be shown on the Virtual Circuit monitor report.

Enabling policies

Policies that are enabled are shown with a green checkmark in the policy tree. Policies that are disabled are shown with a red x. You can toggle the enable state by clicking the checkmark or x.

Related Topics

• Adding a Policy to the Policy Tree
• Policy Ordering Matters
• Re-using Policies from the Library