how to forward alarms to another UIM in separate environment

[Stefan Pivoda]

hi,
what's the best approach to forward alarms from 1 UIM server (20.3.2) to another UIM server (20.3.2) in different environment.
is it snmpgtw? or is there any other better default integration possibility?
the environments should stay separated so configuring the UIM as secondary hub is not possible in this case.
thank you,
stefan

[Keith Kruepke]

In the past--longer ago than I'd care to admit--I managed to get a hub in one domain to connect to a queue on a hub in another domain. I'm not super confident this would still work; it is quite possible that security or other changes in the hub code may interfere with such a setup. I don't remember all of the details, but I don't think it was terribly hard to do. The two hubs need to know about each other, which involves configuring an entry under Static Hubs (in the Name Services tab) on one hub with the details of the other hub. Then they should be able to talk, and in theory you could setup a get queue on one hub with the nimaddress of the other hub.

If this doesn't work, snmpgtw is probably not a bad option. I think you would lose some of the alarm details by sending them via SNMP, but that may be just fine, depending on your use case.

[David Michel]

to move qos and alarm messages from one UIM domain to another, you must setup a tunnel to connect the two domains.

------------------------------
Support Engineer
Broadcom
------------------------------

[Keith Kruepke]

Note that tunnels and static hubs are mutually exclusive. If you use a tunnel (which is sounds like is the only way to make it work), don't create a static hub entry.

[Stefan Pivoda]

Thank you very much David and Keith! the tunnel works based on your suggestions.

only 1 more question as the alarms are successfully forwarded from the "client" hub A to the server hub B, but the alarm_close or any update is not synchronized between them.
so for example, if i open a test alarm on the client hub (and i can see that alarm on the server hub as well), and after that i acknowledge it on the client hub, no update comes to the server hub, so the alarm is still open although it should be closed.
i tried different subjects (* or alarm,alarm2,alarm_close,alarm_update) defined on the attach queue on the client server, but wasnt able to get the wanted result.

usecase 2: what if i want to close(acknowledge) the alarm coming from client hub on the server hub? do i have to create an attach queue on the server hub and a get queue on the client hub in this case? i tried that as well, but didnt work either. 

could you please help with this problem as well?

thank you,
stefan

[Keith Kruepke]

I believe you can only achieve those objectives by setting up NAS replication. The NAS publishes alarm updates to the message bus, those are used by the Alarm SubConsole. As far as I know, you cannot get the NAS to process those messages.

I have no idea whether NAS replication works between domains, which I believe is your situation. I may be assuming a bit much there. If the hubs happen to be in the same domain, replication should be no problem at all.

[Stefan Pivoda]

if the alarm is cleared by UIM itself ( = when the value of the metric goes back to normal), then the synchronization of alarms works fine, so the alarm is cleared on both hubs.
but if any user acknowledges any existing alarm on the client hub, the server hub doesnt get information about it.
i analyzed the queues with Dr Nimbus and i could see that it's the same alarm_close subject in both type of clearing = manual by user or by UIM itself.
so where is the difference, what's the workflow and why doesnt it work only in case of manual clearing? 
thank you.

[Keith Kruepke]

There is *no* synchronization between the two NAS instances the way you have it setup right now. You are simply making 2 copies of each alarm message and sending one to each NAS. Because they get the same messages, they create the same alarms and process the same updates from the probe--including clears. If you have each NAS configured to auto-acknowledge an alarm when it clears, then they will both do that as well--but they do so independently.

The only way to get a pair of NAS instances to actually synchronize is to setup replication between them. This can handle not only creating new alarms but also updates that are initiated from the NAS, such as manual acknowledgement.

[Stefan Pivoda]

yes, i do understand they are 2 different and not synchronized NAS instances. 
but i think (based on what i've seen in Dr Nimbus) that it's the same message/subject on queues that both type of alarm closing generates = 1. manually acknowledging/closing the alarm by user or 2. automaticaly closing the alarm by UIM when the metric goes back to normal state. and in first case it doesnt close the alarm on "server" hub, while in the second case it closes it correctly on both hubs.
sorry to disturbin you, but i'd really appreciate, if you could explain me what's the difference in these 2 types of alarm closing.
thank you, s.

[Keith Kruepke]

The NAS is processing 'alarm' messages from the message bus. (Or it is getting 'alarm2' messages after the alarm_enrichment probe has a crack at them first.) When it does something to an alarm, it posts messages to the message bus with these subjects:

alarm_new
alarm_update
alarm_assign
alarm_close

The Alarm SubConsole subscribes to those messages so that it can update in real time. However, the NAS does *not* process those messages.

As a more specific example, if you acknowledge an alarm in nas1, that will cause it to post an alarm_close message to the bus. Any users with the Alarm SubConsole open will see that alarm disappear because of that message. Nonetheless nas2 will not realize anything has happened because it does not see the alarm_close message.

And even if the NAS queue were setup to capture the alarm_close messages, I don't think NAS will understand what to do with them. It is designed to process alarms from probes, not process messages from other NAS instances.

[Stefan Pivoda]

now, i completely understand why it doesnt work and actually how it works.
@keith i really appreciate your help and time! 
thank you very much!​
s.