Optimizing Bulk IP Address Handling in OCOM

 In Tech Tips, Oracle Communications Session Monitor
Reading Time: 2 minutes

Oracle Communications Session Monitor (aka OCOM or EOM), formerly known as Palladion (still a personal favorite), is a powerhouse in managing multiple devices. But let’s face it, even the best of systems like OCOM can sometimes need a bit of a nudge, especially when dealing with a plethora of IP addresses. Ever wondered how to efficiently manage devices with a vast range of IP addresses, or define a large range when you’re not quite sure of the specifics? Can OCOM handle this smoothly? Absolutely, and here’s how.

It does so simply by allowing you to declare a range of IP addresses using standard CIDR notation when defining a Platform device. But there’s a trade-off.

OCOM’s internal ByIP algorithm is optimized for swiftly checking IP ranges with a /24 mask or larger. However, it’s less efficient with smaller netmask ranges, resorting to a simpler yet slower method. This can impact overall system speed. But don’t worry – there’s an easy fix for this.

So How do I Fix This?

We can fix this by taking advantage of a few simple command-line tools. The following procedure was confirmed on a Linux PC, but the same method should be usable on any system offering a Unix-like operating environment. If you do not use Linux, you are welcome to use the Google Sheet we have created, as an alternative.

Note, it is always better to minimize the number of IP addresses that OCOM has to evaluate, but we recognize that this is not always possible.

Requirements

This requires the following utilities to be available:

  • sipcalc
  • grep
  • awk
  • A command-line

What Do I Do?

Let’s assume you need to break down the range: 192.168.50.0/18

Log into the command-line, and run the following command:

sipcalc 192.168.50.0/18 -s 24 | grep "^Network" | awk '{print $3 "/24"}'

This will generate a long list, which you can just copy and paste directly into the IP address block of the Platform device that you are editing in OCOM. Make sure to remove the original defined address range, if it was in there, as OCOM cannot allow overlapping ranges in it’s device definitions.

And there you go. What might have been a slow and tedious process, completed quickly and easily. And with the benefit of allowing OCOM to take full advantage of its optimized algorithms in the process.

If you would like to know more about the subjects in this article, please get in touch as below.

For more information, view:
SIP Monitoring VoIP for Telco CSPs

Finding Common Threads in Service Level Anomalies Using Big Data Analytics-Voice Quality