NAGIOS: can't seem to get SNMP traps at all...

[u.desilva]

Hi,

we're using build 4.1.1.105 (on Windows Server 2008), and I'm trying to get the Veeam jobs to send their completion status to our Nagios box (Linux, using snmptrapd), but I'm not seeing anything sent from Veeam.

I've configured SNMP destinations in the tools->options->SNMP settings menu, specifying 162 as the port number (for snmptrap), and I've ticked the "send SNMP notification" under the advanced menu of a defined backup job, and run the job manually -- it completes OK, and we get the email notification, but no SNMP packets are seen on the Nagios box.

The Compaq Insight Management agent on the same Windows server is able to send SNMP traps to the same box, so it clearly isn't a network issue.

Does anyone know what I'm doing wrong?

[Vitaliy S.]

Hello Uditha,

Could you tell us if you have uploaded the correct MIB file to your monitoring system to recognize the backup events? Also I would try to look through the job log and find any mentioning of the SNMP trap sending, as it is shown in the example below:

Code: Select all

Info  Task operation: 
Info    Sending snmp trap 'OnVmBackupCompleted' to 1 receivers.
Info    Snmp receiver: IPAddress: 'ivk-2003', Port: '162', CommunityString: 'ampman'
...

You might see the error messages there that could shed some light on the issue. Thanks!

[u.desilva]

From the job log (community string and domain names masked):

Code: Select all

[20.07.2010 13:49:11] <01> Info  Sending email notification, server "eugbbosmt1lp.XXXXX", port 25, timeout 100000
[20.07.2010 13:49:11] <01> Info    Sending snmp trap 'OnBackupJobCompleted' to 1 receivers.
[20.07.2010 13:49:11] <01> Info    Snmp receiver: IPAddress: 'osiris3.XXXXX', Port: '162', CommunityString: 'XXXXXXXXXXXXX'
[20.07.2010 13:49:11] <01> Info    Snmp trap: Trap Id: '.1.3.6.1.4.1.31023.1.1.1.0.1', Name: 'OnBackupJobCompleted' contains 4 objects: 1.[Id: '.1.3.6.1.4.1.31023.1.1.101', 'backupJobId' = '780e6092-bc40-4f0b-b7ed-adcf9eccc09e'] 2.[Id: '.1.3.6.1.4.1.31023.1.1.102', 'backupJobName' = 'VEEAM-TEST'] 3.[Id: '.1.3.6.1.4.1.31023.1.1.103', 'backupJobResult' = 'Success'] 4.[Id: '.1.3.6.1.4.1.31023.1.1.104', 'backupJobComment' = 'Checking retention policy...\n1 rollback point(s) have been deleted.\n'] 
[20.07.2010 13:49:11] <01> Error  Can't send snmp trap "OnBackupJobCompleted" to "osiris3.XXXXX".   at Veeam.Backup.AgentProvider.CSnmpService.Send(CSnmpReceiverData receiver, CSnmpTrap trap)
[20.07.2010 13:49:11] <01> Error     at Veeam.Backup.Core.CSnmpTrapSender.TrySendTrap(CSnmpReceiverData receiver, CSnmpTrap trap)
[20.07.2010 13:49:11] <01> Error  Undefined SNMP error   at VeeamSnmp.ServiceClass.Send(Receiver i_Receiver, Value[] i_Data)
[20.07.2010 13:49:11] <01> Error     at Veeam.Backup.AgentProvider.CSnmpService.Send(CSnmpReceiverData receiver, CSnmpTrap trap)

So it seems it tries to send the trap to the right host and port and community string but doesn't get anywhere. When I changed the hostname to the IP address, the trap was duly sent. So it seems to me that Veeam isn't doing the hostname lookup correctly -- whereas Windows itself seems to be able to do so correctly:

Code: Select all

C:\>ping osiris3.XXXXX

Pinging osiris3.XXXXX [172.21.65.82] with 32 bytes of data:
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63

Ping statistics for 172.21.65.82:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>ping osiris3

Pinging osiris3.XXXXX [172.21.65.82] with 32 bytes of data:
Reply from 172.21.65.82: bytes=32 time=1ms TTL=63
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63
Reply from 172.21.65.82: bytes=32 time<1ms TTL=63
Reply from 172.21.65.82: bytes=32 time=1ms TTL=63

Ping statistics for 172.21.65.82:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

I can live with using IP addresses for now but it would of course be better to use hostnames.

[Vitaliy S.]

Hi Uditha,

Thank you for posting the resolution, I will ask our QA team to try to reproduce this, but as far as I know no other customers have reported SNMP DNS issues before, so this issue may be specific to your environment. Glad that you're up and running now!

[Gostev]

Windows is probably using WINS to resolve after DNS resolution fails, which is why it is successful.

[SteveNeruda]

Had the same problem. Had it configured with a fully qualified domain name and checked the reverse record and it was correct also. Switching to an IP address is working for now.

[Vitaliy S.]

Steve, you're right, it is a known issue mentioned in the Release Notes. This bug should be fixed in our next releases.