Implementing SLM Unicast Peer Group in Datapower

SLM has the ability to monitor traffic and take action if traffic patterns meet certain criteria. For example, consider the case where you have a backend that can only process 300 transactions per second (TPS). SLM can be used to take action when more than 300 TPS inbound transactions are received.

DataPower can be used to ensure this capacity is not exceeded or to send notifications to ensure that any overage is appropriately billed.

DataPower SLM can take action at a transaction threshold in three ways:

Notify: DataPower can send a notification to its logging system via any protocol supported by the device including e-mail, WebSphere MQ, and HTTP. For example, in the case where the REST customer has met its capacity, DataPower could send a notification to a business process that notifies the customer.

Shape: DataPower can delay traffic in an attempt to keep the transaction rate at the given threshold. Take the example where the backend can only process 300 TPS. Here, shaping can be used to queue any transactions that exceed that rate.

Throttle: DataPower can reject transactions that exceed the given threshold.

SLM is supported on multiple appliances that share load with SLM peer groups. The appliances in a peer group continuously communicate with each other to ensure SLM thresholds are shared across the entire group.

A peer group is a collection of DataPower appliances that exchange service level data to enforce SLM policies in the group. A peer group establishes a data-sharing protocol. The traffic that each appliance in the group processes is passed to the other peers to calculate whether a threshold is reached.

Check that all the criteria below is met for creating SLM Peer Group:

1. All the DataPower Appliances must be clock-synchronized. You can use the NTP service.

2.  The XML Management Interface has to be enabled on both devices.

3. Ensure that there is no firewall in between the appliances blocking the port for the XML Management Interface.

4. Review the XML Management Interface configuration and check the advanced tab, to ensure, the default user agent is not used, or if used, that it has been set up with an SSL Proxy Profile.

5. SLM Peer Groups communicate over XML Management Interface (XMI), and XMI uses SOAP over HTTPS to exchange data. If specifying the “Custom User Agent” property of the XMI and you have an “SLM Peer Group” configured, you must make sure to have an SSL Proxy Profile defined in the “Custom User Agent”.

6. If this was not the case, the outbound request with the “Custom User Agent” property set is not processed by the other appliance in the “SLM Peer Group”.

7. To exchange SLM data at periodic interval, peer members must have identical SLM configurations, including the members list.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

8. Ensure that the URLs in the peer group are correct

9. When using hostnames in the peer group URLs, make sure you have a working DNS configuration

10. The SLM policy needs to be identical on both appliances. If they do not match, the peering will not work.

11. SLM Interval length agreement:

An SLM Policy allows administrators to set a threshold level interval set on the SLM Policy Statements page.

When an SLM Policy being enforced by more than one device, administrators must also set a SLM update Interval on the SLM tab of the XML Management Interface configuration page found only in the default domain.

The SLM update Interval must be equal to or less than the threshold interval set in any SLM Policy statement in use on the device. If not, the updates deliver outdated information to the individual policies and are ignored, defeating the purpose of peering.

12. Use the same packet transmission method: unicast or multicast.

13. SLM unicast peering

SLM unicast peering uses unicast packet transmission to update peers in a connected manner.

Consider SLM unicast peering when:

1. DataPower appliances in the peer group are not physically close or not connected within the same sub network.
2. The rate of incoming data is low or moderate.
3. The data sharing interval equals to or is more than one second.

14. SLM multicast peering

SLM multicast peering uses IP multicast packet transmission to update peers in a connectionless manner. Multicast peering supports small threshold intervals and allows data sharing intervals of less than one second.

Consider SLM multicast peering when:

1. DataPower appliances in the peer group are physically close and connected within the same sub network.
2. The rate of incoming data is high.
3. The data sharing interval is less than one second, and you need higher SLM peering accuracy.
4. The peering traffic and the data traffic use separate networks.

To define a peer group using SLM Unicast:

1. Click Objects → Network → Peer Groups.
2. Click Add.

3. In the Name field, enter the name for the configuration.

4. Set Administrative State to identify the administrative state of the configuration.

5. Optional: In the Comments field, enter a descriptive summary.

6. From the Type list, select the type of SLM peering for packet transmission.

7. For SLM unicast peering, specify the IP unicast configuration and update interval to exchange data among peers.

In the URL field, enter the URL of each peer, including the local appliance, and click Add.

8. Click Apply to save the changes to the running configuration.

9. Optional: Click Save Config to save the changes to the startup configuration.