requests followed by long inbound responses.
A surf-in pipe is therefore first created for inbound traffic with a 125 kbps limit. Next, a new Pipe
Rule is set up for surfing that uses the surf-in pipe and it is placed before the rule that directs
everything else through the std-in pipe. That way web surfing traffic goes through the surf-in pipe
and everything else is handled by the rule and pipe created earlier.
Unfortunately this will not achieve the desired effect, which is allocating a maximum of 125 kbps to
inbound surfing traffic as part of the 250 kbps total. Inbound traffic will pass through one of two
pipes: one that allows 250 kbps, and one that allows 125 kbps, giving a possible total of 375 kbps of
inbound traffic but this exceeds the real limit of 250 kbps.
The Correct Solution
To provide the solution, create a chain of the surf-in pipe followed by the std-in pipe in the pipe
rule for surfing traffic. Inbound surfing traffic will now first pass through surf-in and be limited to a
maximum of 125 kbps. Then, it will pass through the std-in pipe along with other inbound traffic,
which will apply the 250 kbps total limit.
Figure 10.3. Differentiated Limits Using Chains
If surfing uses the full limit of 125 kbps, those 125 kbps will occupy half of the std-in pipe leaving
125 kbps for the rest of the traffic. If no surfing is taking place then all of the 250 kbps allowed
through std-in will be available for other traffic.
This does not provide a bandwidth guarantee for web browsing but instead limits it to 125 kbps and
provides a 125 kbps guarantee for everything else. For web browsing the normal rules of first-come,
first-forwarded will apply when competing for the 125 kbps bandwidth. This may mean 125 kbps,
but it may also mean much slower speed if the connection is flooded.
Setting up pipes in this way only puts limits on the maximum values for certain traffic types. It does
not give priorities to different types of competing traffic.
10.1.6. Precedences
The Default Precedence is Zero
All packets that pass through NetDefendOS traffic shaping pipes have a Precedence. In the
examples so far, precedences have not been explicitly set and so all packets have had the same
10.1.6. Precedences
Chapter 10. Traffic Management
457
Summary of Contents for NetDefend DFL-260E
Page 27: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 27...
Page 79: ...2 7 3 Restore to Factory Defaults Chapter 2 Management and Maintenance 79...
Page 146: ...3 9 DNS Chapter 3 Fundamentals 146...
Page 227: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 227...
Page 241: ...5 4 IP Pools Chapter 5 DHCP Services 241...
Page 339: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 339...
Page 360: ...7 4 7 SAT and FwdFast Rules Chapter 7 Address Translation 360...
Page 382: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 382...
Page 386: ...The TLS ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 386...
Page 439: ...Figure 9 3 PPTP Client Usage 9 5 4 PPTP L2TP Clients Chapter 9 VPN 439...
Page 450: ...9 7 6 Specific Symptoms Chapter 9 VPN 450...
Page 488: ...10 4 6 Setting Up SLB_SAT Rules Chapter 10 Traffic Management 488...
Page 503: ...11 6 HA Advanced Settings Chapter 11 High Availability 503...
Page 510: ...12 3 5 Limitations Chapter 12 ZoneDefense 510...
Page 533: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 533...
