Optimizing Bulk IP Address Handling in OCOM

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

Oracle Communications Session Monitor, known variously as OCOM, EOM and formerly Palladion – still a personal favorite – is a powerful system, capable of handling hundreds of devices with ease. But even it can need a helping hand, from time to time. So how does it handle devices that respond to hundreds of IP addresses, covering a large range? Or ones where you need to define a large range, simply because you’re not sure exactly what individual addresses are necessary? Can OCOM deal with this?

Yes. Yes, it can. And 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 tradeoff.

Internally, OCOM uses an optimized algorithm, known as ByIP, that allows it to to quickly and efficiently check ranges with a mask of /24 or larger, but this breaks down when it needs to evaluate ranges with smaller netmasks, and it is forced to abandon the optimized algorithm, to fall back on a simpler, and slower method, which slows down the entire system. Fortunately, there’s a simple way to fix 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. Other solutions are certainly possible, but we’re not going to try and go into these here.

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.


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:

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

sipcalc -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.

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