Hi,
I know that DataMiner elements will keep the DMA_ID and Element ID from the source DMA when a migration is performed, this is in order to keep the relationships within the database with the DMA id and the Element id.
We run into a situation where DataMiner team IP in the alarms messages sent towards the northbound interface is different from the DataMiner agent IP to which the CMTS hosted by, below are the details.
** As a reference, here are the DMA name, ID and IP**
SVDMA2206002PR 42017 10.176.226.145
SVDMA2103001PR 42010 10.178.226.140
*********************************************
We can see that the DMA id associated to this element is 42010 (which would correspond to the VIP 10.178.226.140), but the actual DMA hosting the element is SVDMA2206002PR (42017).
However, at the northbound interface app (Netcool), they are receiving that the IP address to which the element belongs to is 10.178.226.140 which is the IP that corresponds to 42010 and not from svdma2206002pr (42017 10.176.226.145) which is actually hosting the element:
Another example of this would be:
*************************************
SVDMA2101001PR 42009 10.178.226.137
SVDMA2206002PR 42017 10.176.226.145
*************************************
We can see that the DMA id associated to this element is 42009 (which would correspond to the VIP 10.178.226.137), but the actual DMA hosting the element is SVDMA2206002PR (42017).
However, at the northbound interface app (Netcool), they are receiving that the IP address to which the element belongs to is 10.178.226.137 which is the IP that corresponds to 42009 and not from svdma2206002pr (42017 10.176.226.145) which is actually hosting the element:
So the question here would be: Is this behavior expected? Which IP should be appearing in the northbound interface for each element?
Should it be the Hosting DMA id (the id of the server managing the element) or the DMA id ( of the server where the element was created originally.)
In these 2 cases, the IP listed is from the DMA id of the server where the elements were originally created and not the hosting IP. Is this expected?
Thanks in advance,
Hi Carlos, Thank you for your clear and comprehensive explanation of your issue.
I would expect that the source IP should be the one of the agent that hosts the element. (Unless the SNMP Manager is explicitly configured to send the notifications by a pre-defined agent. See ‘Send all notifications via one DMA’ option.)
I have tried to replicate your issue on a recent DataMiner version by creating an element on agent A of a cluster, and then moving it to agent B. I then had the same setup where the DataMiner ID of the element matches the ID of agent A, but it is hosted on agent B. When I then created an SNMP Manager that forwards all alarms for this element to some receiver on my local machine, I saw that these alarms were correctly forwarded with the source IP of DMA B. (The hosting agent)
It seems that there is some difference between our setups. Could you share the DataMiner version that these agents are running?
It seems that there is quite a big version difference here (9.6.0 CU23 vs. 10.1.7). My colleague tried this on the upcoming 10.0.0 CU16 version, and it also works correctly on that one. There must have been some fix/change between these versions that resolved this issue. I checked if there are any Release Notes that would match this, but was unable to find anything related. I can only assume that there was some indirectly related fix/change that rectified this forwarding behavior. Unfortunately, I won’t be of much help anymore.
Hi Thomas, thank you very much for trying to replicate this. Hopefully there is someone that can read this and confirm if this is the appropriate behavior on 9.6 CU23 or if this is an issue.
Hi Carlos,
We were trying to replicate this issue using DMA version 9.6.0 CU23 but without success. However, our test setup was limited to export/import between single DMAs (we didn’t test this behavior in a cluster setup).
In order to further investigate this issue we will need the following information:
– Detailed information about the SNMP Manager configure in the ‘new DMA’
– Wireshark capture of the trap sent to Netcool
HI Thomas,
Thank you very much for your response and for trying to replicate this.
In this case, we don’t have the SNMP managers to send all notifications via one DMA, so each SNMP manager should be sending the alarms of their own elements.
We have done another test also after the migration, where the DMA ID of the element is the same DMA ID of the hosting DMA, and the IP displayed in the SNMP receiver matches this, so we can rule out that the notifications are being sent via one DMA.
These DMAs are running on version 9.6.0 CU23