Server Management - Systems Insight Manager
1827311 Members
2628 Online
109961 Solutions
New Discussion

SNMP Traps from RHEL Clients not using bond0 address in agent-addr field

 
richii
New Member

SNMP Traps from RHEL Clients not using bond0 address in agent-addr field

I'm currently using Red Hat EL 5.6 with PSP 8.7 for our client machines (HP DL 380 G7's), all of which point to HP Systems Insight Manager 6.3 running on Windows 2008 R2

 

The problem I'm having is that when the Red Hat clients send an SNMP trap, they are ignored by HP SIM because the agent-addr field in the message contains the IP address of the backup interface rather than the public one.

On a typical host, we have:

bond0 - public interface - bonded between eth0 and eth4
eth1 - Veritas Heartbeat
eth2 - backup interface
eth5 - Veritas Heartbeat

In /opt/hp/hp-snmp-agents/cma.conf I have set the following so that it forces the public interface to be used:

trapIf bond0

When I attempt to send a test SNMP trap via HPSMH, the message is sent out correctly on bond0, however it contains the backup interface (shown in RED):

09:01:53.899690 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 145) 10.191.96.1.18895 > 192.168.40.1.snmptrap: [bad udp cksum 91fa!]  { SNMPv1 C=CommunityString { Trap(99)  .1.3.6.1.4.1.232 172.26.176.1 enterpriseSpecific s=11003 51852 .1.3.6.1.2.1.1.5.0="adsvams02" .1.3.6.1.4.1.232.11.2.11.1=0 .1.3.6.1.4.1.232.11.2.8.1="Test Trap" } }

 

 

Are there any other settings that need to be made to force SNMP traps to use the bond0 IP address in agent-addr?

Only other thing, I noticed that the "cold start" messages generated when the snmpd service starts were also sending out messages with the backup interface.  I logged this with Red Hat, and they suggested the following in /etc/snmp/snmpd.conf:

v1trapaddress 10.191.96.1

(Where this address is the public interface on bond0)

After doing this, I now see cold start messages with the correct agent-addr data.  However, test SNMP traps generated via HPSHM are still incorrectly referencing the backup interface.