Hi,
We are currently developing multicast monitoring, what we did was ask solarwind to compile multicast MIB file. From there costumze view can be developed.
I think Orion 9.5.1 is close to what we need. We simply need to poll a router (Cisco usually) and get the active mroutes, and their BPS. We also need the ability to enumerate the multicast IP addresses to real-world textual descriptions.
I say close because we're still actively hitting the market trying to find a solution for this. Sounds simple.
With the new custom poller, we can return a table. That is huge. Case in point is OID 1.3.6.1.4.1.9.10.2.1.1.2.1.31. This is the entire mroute table and the active BPS passing thru the device. The only stopping point right now is (first) the ability to pair these values with the textual return from the row header containing the S,G information (1.3.6.1.4.1.9.10.2.1.1.2.1), second, the ability to "filter" the rows (in our case, ciscoIpMRouteBps2 > 0), and third the ability to enumerate the S,G information to a real-world textual description (239.1.1.1 10.22.X.X.255.255.255.255 = "CHANNEL 132").
With these small tweaks to the Universal Device Poller and the CISCO-IPMROUTE-MIB, MROUTE-MIB, and MROUTE-STD-MIB actually active - Orion is "close" to being able to declare itself a multicast management platform. I would pay for this capability. It would save me from implementing an entirely separate network management platform for that specific purpose.
Did this feature/addon every progress? On NPM you can view the multicast traffic on an interface via pps. I'm looking for a tool that displays multicast groups being subscribed to by a server/workstation.
Bump!
Any updates?
Unfortunately we have not done much recently to address the pain points around managing multicast. We have made updates recently to allow for alerting on table pollers, but there is still a gap from what you need. Can you leverage logging messages for this?
Now available in NPM 10.5
This has to be the most useless feature to date. Here is why. Now please correct me if I'm wrong.
The alerts give no indication to what the problem is or where the source is for the multicast group. Two key things when you have to manage multiple thousands of groups. So I get a ton of alerts with no insight into why it's happening or where. I turned it off because it was so useless and was flooding my alert monitoring.
I agree but worse than that it caused repeated database deadlocks causing us to go as far as reboot the SQL server one or more times per day to clear the mess up. Support gave us a SQL script to delete all the multicast pollers from the database and disable a stored procedure. Now we're pretty stable on 10.5
hi rgward,
this is something that should be fixed in NPM 10.6 RC.
@johndpeeknd - I appreciate your feedback. We have developed this feature for users that intensively use multicast data and they are satisfied with this V1 - mainly because of multicast group and multicast topology information. The use case here is to focus on groups and mutlicast routers in your network. It won't tell you who inside the subnet that's subscribed to the multicast group having the issues - client/end station. But typically, if there is an issue, it's caused by problem in whole network segment not just a single client (but I agree that this would be very nice to have there).
If you can describe what exactly you are trying to solve I'd would be happy to include this into multicast future enhancements.
