Amer Networks E5Web GUI - Manual (Page 681)

Unintended Consequences
To explain this unintended traffic shaping, consider a client A that connects to host X with P2P
traffic and triggers an IDP rule with the Pipe action so the connection becomes subject to traffic
shaping. Now, if another client B also connects to host X but this time with web surfing traffic, an
IDP rule is not triggered but the connection should not be traffic shaped along with client A's
connection just because host X is involved.
Excluding Hosts
To avoid these unintended consequences, we specify the IPv4 addresses of client A and client B
in the Network range but not host X. This tells cOS Core that host X is not relevant in making a
decision about including new non-IDP-triggering connections in traffic shaping.
It may seem counter-intuitive that client B is also included in the Network range but this is done
on the assumption that client B is a user whose traffic might also have to be traffic shaped if they
become involved in a P2P transfer.
If Network is not specified then any connection involving either client A or host X will be subject
to traffic shaping and this is probably not desirable.
10.2.5. A P2P Scenario
The schematic below illustrates a typical scenario involving P2P data transfer. The sequence of
events is:
• The client with IP address 192.168.1.15 initiates a P2P file transfer through a connection (1) to
the tracking server at 81.150.0.10.
• This connection triggers an IDP rule in cOS Core which is set up with an IDP signature that
targets the P2P application.
• The Pipe action in the rule sets up a traffic shaping pipe with a specified capacity and the
connection is added to it.
• A subsequent connection (2) to the file host at 92.92.92.92 occurs within the IDP rule's Time
Window and its traffic is therefore added to the pipe and is subject to shaping.
• The client network to which 192.168.1.15 belongs, should ideally be included in the Network
address range for the IDP rule.
Chapter 10: Traffic Management
681