I'm working on setting up SNMP trap delivery from our ICM application to an HP Openview NMS server.
I understand that the application level traps are all forwarded by the Logger rather than from individual componants, and I have that workinf in a lab environment for my SideA Rogger. My question is what to expect between the A and B sides? I'm having difficulty getting the B side set up and working and I am not sure if it is not sending alerts because the A side is active and it only sends when A is down (still doesn't work when I stop the A side services, so I'm not yet sure what is going on). What should I expect here?
Dows the side B logger only foward to the NMS when it sees side A is down or unreachable, or, if I configure both A and B side loggers to send SNMP alerts, will I see duplicates of the alerts, one from each machine? The available Cisco documentation, like the ICM 7.x.y Serviceability Best Practices Guide is decidedly unclear about configuration and interaction of the A and B side loggers for this process, so any help would be greatly appreciated!
I think you have misunderstood the documents. Each node is configured with the Cisco SNMP Agent and the standard Windows SNMP Agent is disabled. Each agent is responsible for sending traps on the specified Community Name to the specified IP address targets, and can accept SNMP GETs from the list of specified IP addresses (you can open this up, but most people don't).
You have to go onto each ICM node and add the Cisco SNMP SnapIn to the MMC and configure SNMP.
The Logger thing you are thinking of is the Syslog feed. All components talk to the Logger and the Logger sends these events through the normal port to a Cisco Syslog receiver. I don't bother with this, although I normally allow the process to run in case someone wants it later.
Cisco has done a lot of work on SNMP over the last few years and it's pretty solid and extensive. Please check again. It works just how you would want it to work.
Actually Geoff, I have to argue that you are incorrect. I understand the ICM SNMP well enough to have it working in our Lab environment. I've read, re-read, and read yet again through the Serviceability Best Practices Guide.
The guide specifically states:
SNMP notifications generated by the contact center application are always generated as SNMP traps from the Logger; only generic traps or traps from other subagents (such as the platform subagents provided by Hewlett Packard or IBM) will be generated from Unified CCE nodes other than the Logger.
I'm not interested in the machine level traps from HP or IBM, our servers are managed by another team who handle machine/OS level monitoring, so I don't care about configuring the individual nodes to send traps from thier subagents. I am only interested in the ICM application level alerts.
The Syslog feed is also still available and works the same way, but I'm not using it and not interested in it.
Again, the issue I have is not understanding how the two loggers interact when both are configured to send traps. Does the side B logger understand not to send them when A is up and active, or do I get duplicated traps, one from each side, in which case configuring the B side to send traps is not advisable?
There is an SNMP agent installed on the box that enables the SNMP GET (and SET if you allow) to ascertain the health of the system by fetching the process table and checking processes against a master list. These are certainly not being proxied through the Logger.
But regarding the traps from ICM events - your quote is clear enough and definitive.
It makes me wonder why they do it this way. Since we have to go onto each node and configure the trap destinations (for the non-ICM traps to reach their targets) why don't the ICM traps go that route? It could be to keep the syslog processing as an alternative.
This diagram is from Networkers last year.
But now that we are in agreement on how it works, let's go back to your question.
The CSFS (Customer Support Forwarding Service) process on the Logger sends the message to the CCA-MIB Sub Agent which then uses the Master Agent (Cisco SNMP Agent) to send out the trap.
I imagine CSFS has an active-idle concept to prevent duplication of traps.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...