Exinda EXNV-10063, Administration Manual

Page: 272 / 623

Exinda Network Orchestrator 3 Using | 272
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.
NOTE
Special care is needed when creating virtual circuits based on limiting the number of active connections, or limiting
the number of active hosts, or providing fair sharing between the active hosts. When a connection or host limit is
reached, it will not longer match any incoming traffic. Therefore, connections or hosts that arrive later will be
evaluated against the remaining virtual circuits in the circuit. You should ensure that the overflow connections or
overflow hosts are handled according to your business needs by creating a virtual circuit immediately after the
virtual circuit based on limits that deals with that traffic appropriately.
Later, once some of the active connections or active hosts in the virtual circuit terminate, the virtual circuit will be
used to match new traffic again.
EXAMPLE
Consider the scenario where the first circuit is defined to match bridge br10, the first virtual circuit within that circuit
is defined to match the subnet for a particular branch site Springfield, and the first policy within that virtual circuit is
defined to match P2P traffic.
Traffic arrives. If the traffic arrives on br10, then it is evaluated against that circuit's first virtual circuit. If the traffic
matches against the Springfield subnet, then it is evaluated against its first policy. If the traffic matches P2P, then the
action within the P2P policy is taken.
In each case, if the traffic did not match a given circuit, then the traffic would be evaluated against the next circuit. If
the traffic did not match a given virtual circuit in the circuit that was matched, then the traffic would be evaluated
against the next virtual circuit. If the traffic did not match a given policy in the virtual circuit that was matched, then
the traffic would be evaluated against the next policy.