How to Monitor Cisco CUCM in Appneta

Products

• AppNeta

Issue/Introduction

Attempting to monitor a Cisco CUCM environment where a rate limiting Queue technique may be applied on CUCM

In this situation, a lower Packets per Burst (e.g. 5) should be attempted if a rate limiting queue technique is suspected. If this action makes packet loss disappear, then it is highly likely that a rate limiting queue has been implemented.

However, adjustments made to the number of packets sent in the advanced test setting "Packets per burst" where increasing this value improves resolution but also increases network load. Decreasing this value has the opposite effect.

What should be done?

Resolution

The CUCM firewall (iptables) has a rate limiting rule for ICMP packets:

• A INPUT -p icmp -m limit --limit 10/second -j ACCEPT


• A INPUT -p icmp -m limit --limit 1/minute -j LOG --log-prefix "ping flood " --log-level warning

• A INPUT -p icmp -j DROP

What these rules do is:

• As long as the rate of ICMP packets is less than 10 per second, we will jump (-j) to ACCEPT, and the response will be sent.
  
  
• If the rate goes over 10 per second, we will jump to LOG, and an entry will be added to the messages file with this type of prefix: ping flood IN=eth0 OUT= MAC=
  
  
• Since there is a rate limit of 1 log per minute, you will only see one of these drops. If the ICMP packets are still coming in at more than 10 per second, you will see another log entry in a minute

But 10 packets/s (pps) is very low, regardless of tartget type. The simplest approach would be increase the rate limit to 50pps - you could be fairly confident of having a path work well and still be protected against DOS. However, you'd have to ensure there are not multiple paths hitting that target.

So there is not much we can mitigate from the Monitoring Point (MP) side, but you should increase the rate limit to 50pps if possible. The other approach is for you to not target the CUCM and deploy a 2nd MP within its same network to target.