We want to keep a consumer from flooding the providers especially when the providers start to slow down for any reason. (Consumer-->DP-->Provider).
We are setting up an SLM Policy with the Threshold Interval Type set to Concurrent. We plan to throttle the traffic if they exceed X Threshold level and notify if its 80% X. I read this article that says it is recommended to not use Peer Groups when the resource type is concurrent. In our case we are not using a resource type but we are setting the threshold interval type to concurrent. Is it recommended to use SLM multicast peering in our scenario and this article only applies to unicast?
An SLM policy configured to limit either the number of concurrent connections from a given user or the number of concurrent transactions into the service works as expected when implemented on one device. If the environment is expanded to include a similarly configured peer device, adding a peer group to that SLM policy is not a supported option.Cause
This is a known limitation of the SLM facility. The Concurrent Connections and Concurrent Transactions Resource Types are not supported in the SLM Peer Group scenario. They rely on an instantaneous measurement, while peering is implemented based on the exchange of historical averages.
In general, SLM peer groups allow administrators to configure a set of appliances to share SLM data about a common service.
For most resource types, the SLM policy will use this shared data in the configured Threshold algorithm while processing the policy.
In the case of Concurrent Transactions or Concurrent Connections, however, the policy will use the instantaneous value on the device and will not incorporate data from the peer group.
It is possible to work around this issue in a limited way by reducing the Concurrent thresholds on each peer device (for example, for 2 devices divide in half, for 4 divide into quarters, etc.); however, this is not an ideal solution. The best practice is to use these concurrent resource types without a Peer Group, for protecting the individual DataPower appliance or configured services, and to use another method for protecting the back-end service.
Keep in mind that this is a permanent limitation with the original implementation of the SLM peering feature. Firmware version 5.0.0 introduces a new type of peering, SLM Multicast Peering, which is not affected by this limitation. SLM Unicast Peering, the type that was previously available, continues to have the limitation in release 5.0 and later.