Relying on the Group Limit
A special case when a total pipe limit is not specified is when a group limit is used instead. The
bandwidth limit is then placed on, for example, each user of a network where the users must
share a fixed bandwidth resource. An ISP might use this approach to limit individual user
bandwidth by specifying a "Per Destination IP" grouping. Knowing when the pipe is full is not
important since the only constraint is on each user. If precedences were used the pipe maximum
would have to be used.
Limits should not be more than the Available Bandwidth
If pipe limits are set higher than the available bandwidth, the pipe will not know when the
physical connection has reached its capacity. If the connection is 500 Kbps but the total pipe
limit is set to 600 Kbps, the pipe will believe that it is not full and it will not throttle lower
precedences.
Limits should be less than Available Bandwidth
Pipe limits should be slightly below the network bandwidth. A recommended value is to make
the pipe limit 95% of the physical limit. The need for this difference becomes less with increasing
bandwidth since 5% represents an increasingly larger piece of the total.
The reason for the lower pipe limit is how NetDefendOS processes traffic. For outbound
connections where packets leave the NetDefend Firewall, there is always the possibility that
NetDefendOS might slightly overload the connection because of the software delays involved in
deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed
by the traffic shaping subsystem and it is therefore more important to set pipe limits slightly
below the real connection limit to account for the time needed for NetDefendOS to adapt to
changing conditions.
Attacks on Bandwidth
Traffic shaping cannot protect against incoming resource exhaustion attacks, such as DoS attacks
or other flooding attacks. NetDefendOS will prevent these extraneous packets from reaching the
hosts behind the NetDefend Firewall, but cannot protect the connection becoming overloaded if
an attack floods it.
Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing
through that bottleneck passes through the defined NetDefendOS pipes.
If there is traffic going through the Internet connection that the pipes do not know about,
NetDefendOS cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic
"leaking" through without being measured by pipes will have the same effect as bandwidth
consumed by parties outside of administrator control but sharing the same connection.
Troubleshooting
For a better understanding of what is happening in a live setup, the console command:
Chapter 10: Traffic Management
792
Summary of Contents for NetDefendOS
Page 30: ...Figure 1 3 Packet Flow Schematic Part III Chapter 1 NetDefendOS Overview 30 ...
Page 32: ...Chapter 1 NetDefendOS Overview 32 ...
Page 144: ...Chapter 2 Management and Maintenance 144 ...
Page 284: ...Chapter 3 Fundamentals 284 ...
Page 392: ...Chapter 4 Routing 392 ...
Page 419: ... Host 2001 DB8 1 MAC 00 90 12 13 14 15 5 Click OK Chapter 5 DHCP Services 419 ...
Page 420: ...Chapter 5 DHCP Services 420 ...
Page 573: ...Chapter 6 Security Mechanisms 573 ...
Page 607: ...Chapter 7 Address Translation 607 ...
Page 666: ...Chapter 8 User Authentication 666 ...
Page 775: ...Chapter 9 VPN 775 ...
Page 819: ...Chapter 10 Traffic Management 819 ...
Page 842: ...Chapter 11 High Availability 842 ...
Page 866: ...Default Enabled Chapter 13 Advanced Settings 866 ...
Page 879: ...Chapter 13 Advanced Settings 879 ...