Exinda Network Orchestrator
3 Using
|
321
feature enabled on the Exinda appliance at headquarters identifies that appliance as the end of the acceleration chain
and will prevent the appliance from sending the TCP option 30 on the SYN packet to the Internet.
If, however, you have a hub-and-spoke topology, where the Exinda Appliance at headquarters could either be the end
of the acceleration chain when backhauling Internet traffic or it could be an Exinda in the middle for traffic transported
between distributed branches via the headquarters, you will not want to enable this feature.
To learn more about this feature, see
.
3.5.3 Setting and enforcing quotas
Quotas are an effective way to enforce fair sharing of the network or to ensure customers receive only the amount of
access to the network for which they have paid. Quotas can enforce caps based on a data transfer amount or based on
the amount of time on the network. After the quota has been reached, a variety of actions could take place, such as
throttling or blocking all data, or throttling only particular types of traffic, or redirecting the user to a particular webpage.
To support quota enforcement scenarios, you need to configure the following:
1.
Create an adaptive response limit object to define how the quota is measured and to identify the users that have
exceeded their quota by using a named network object. The adaptive response object can specify whether to set a net-
work-traffic data-volume limit or a time limit. The adaptive response object identifies the traffic that is monitored against
the specified quota as a network object. The network object can either be based on IP addresses, or based on Active Dir-
ectory users or user groups. The adaptive response object tracks those that have exceeded their quota by dynamically
adding them to a named network object.
2.
Add a policy (or policies) to the Optimizer policy tree for those who are over their limit. The policy that addresses
those that have exceeded their quota is defined according to your business needs. You can choose to throttle their
traffic or block it entirely. When they have HTTP traffic, you can also choose to redirect them to a webpage that you host
or respond with a webpage that the Exinda Appliance hosts. If needed you can combine these, such that the first policy
filters for HTTP traffic and then shows a webpage, but then other types of traffic are caught by a second policy that
blocks the remaining traffic.
3.
Add policies to the Optimizer policy tree for those under the limit. The remaining policies define how to deal with
the traffic of the users who have not yet exceeded their quota.
NOTE
Since the Exinda Appliance attempts to match the traffic to the filters in the policies (and virtual circuits) in the top-
down order defined in the Optimizer policy tree, you need to set up the series of policies with the most specific
filter criteria appearing first in the policy tree, which means the policies should appear in the following generalized
order.
Those who have exceeded their quota and have HTTP traffic
Those who have exceeded their quota and have other types of traffic
Remaining traffic (that is, those who have not exceeded their quota)
To learn more about the individual components needed for quota enforcement, see
,
,
Configure HTML Response Object
and
.
Example: Each user has a 10GB capped data quota
Consider an educational institution that has a group of students who have IP addresses in the subnet 192.168.0.0/16.
Each student is allowed 10GB data transfer (uploads and downloads) per month. After the limit is reached, they are
allowed no more data.
Summary of Contents for EXNV-10063
Page 369: ...Exinda Network Orchestrator 4 Settings 369 ...
Page 411: ...Exinda Network Orchestrator 4 Settings 411 Screenshot 168 P2P OverflowVirtualCircuit ...
Page 420: ...Exinda Network Orchestrator 4 Settings 420 Screenshot 175 Students OverflowVirtualCircuit ...
