traffic shaping - by ip subnet

[nflnetwork29]

I am searching for a way to implement some traffic shaping on a per subnet basis. 

We have a hub and spoke type topology where ALL traffic flows thru a central location (Datacenter) w/ a pair of 6200's in Cluster XL. 

and another question does the checkpoint implement flow control by default???

thanks 

[Chris_Atkinson]

What's possible from a QoS perspective is covered in the QoS admin guide:

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_QoS_AdminGuide/Default.htm

Application Control additionally has a "limit" feature.

[Timothy_Hall]

There are three ways to do limits, listed below in increasing order of capability & complexity:

1. If you just want to do simple bandwidth limits, as Chris said you can enforce a per-rule limit from the Action field of a policy layer that has APCL/URLF enabled.
2. You can also have SecureXL impose various limits including bandwidth, connection rate, total concurrent connections, packet rate, byte rate, etc.  See section 5 covering fwaccel dos here: sk112454: How to configure Rate Limiting rules for DoS Mitigation (R80.20 and higher)
3. Finally there is the QoS blade which can enforce weighted fair queuing, per-connection & per-rule limits, per-rule & per-connection bandwidth guarantees, ToS differentiated services, low latency queuing and more.  Note that use of QoS now no longer dooms shaped traffic to the F2F/slowpath starting in R80.20, and therefore is now a quite viable option.

When you say "flow control" I assume you are talking about Ethernet flow control (pause frames)?  By default most firewall NICs/drivers will have this enabled by default, but most switches including Cisco will have it off by default so there will be no effect.  Generally if flow control is being requested by a firewall NIC it indicates that NIC hardware buffer overruns (RX-OVR) have occurred or are imminent, and you should either use a faster interface if available, or implement a bond.  In some rare cases under heavy load Ethernet flow control and TCP's congestion control algorithm can "butt heads" and actually hurt performance due to a phenomenon known as "head of line blocking".  This was discussed in my Max Power book and as such Ethernet flow control is generally not desirable in most situations.

[nflnetwork29]

thanks for the reply, ya what is happening on our line is the following. 

our main line is 1 Gbps and our destination switch handoff is only 100 Mbps so we are seeing a bunch of dropped packets. (our switch does not have enough buffer)

I belive we want to force the connection speed to 100 Mbps for this one specific connection thru our checkpoint . 

[Timothy_Hall]

Only the QoS blade allows you to declare the upstream speed to a lower value for a particular interface (in your case 1Gbps->100Mbps) and then shape the outbound traffic to fit into the lower bandwidth.  fwaccel dos will just drop everything that exceeds a bandwidth limit, and APCL/URLF limits are only per-rule and not per-interface.  Looks like the QoS blade is the solution here.

[CheckPointerXL]

Hey TImothy, fwaccel dos settings will be lost during an upgrade?

thanks

[Timothy_Hall]

They should not be lost upon upgrade, but for anything that is configured only from the CLI like this it is very important to document these changes, and reverify them after an upgrade/hardware swap.