by I have implemented functionality in our v2c agent to set IP addresses
to receive SNMP trap notifications using a simple table in a
proprietary MIB. I have been asked to modify this to use a more
standard approach such as using the SNMP Target Tables and the SNMP
Notification Tables (from SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB,
rfc 2573). We do NOT have a requirement to use v3 now but at some time
in the future could. I investigated and could not identify any reason
that the use of these MIBS for a v2c Agent might violate standards. I
took a look at the ucd net-snmp toolkit and found that they use the
SNMP-NOTIFICATION-MIB and the SNMP-TARGET-MIB for defining trap
notifications even when configured for v2c. I was able to configure a
simple case in v2c requiring three tables. The snmpNotifyTable from
the SNMP-NOTIFICATION-MIB and the snmpTargetAddrTable and
snmpTargetParamsTable from the SNMP-TARGET-MIB. Below are the results
from querying the tables with one defined trap destination.
The snmpNotifyTable contains:
SNMP-NOTIFICATION-MIB::snmpNotifyTag.'internal0' = STRING: internal0
SNMP-NOTIFICATION-MIB::snmpNotifyType.'internal0' = INTEGER: trap(1)
SNMP-NOTIFICATION-MIB::snmpNotifyStorageType.'internal0' = INTEGER:
readOnly(5)
SNMP-NOTIFICATION-MIB::snmpNotifyRowStatus.'internal0' = INTEGER:
active(1)
The snmpTargetParamsTable contains:
SNMP-TARGET-MIB::snmpTargetParamsMPModel.'internal0' = INTEGER: 1
SNMP-TARGET-MIB::snmpTargetParamsSecurityModel.'internal0' = INTEGER:
2
SNMP-TARGET-MIB::snmpTargetParamsSecurityName.'internal0' = STRING:
public
SNMP-TARGET-MIB::snmpTargetParamsSecurityLevel.'internal0' = INTEGER:
noAuthNoPriv(1)
SNMP-TARGET-MIB::snmpTargetParamsStorageType.'internal0' = INTEGER:
readOnly(5)
SNMP-TARGET-MIB::snmpTargetParamsRowStatus.'internal0' = INTEGER:
active(1)
SNMP-TARGET-MIB::snmpUnavailableContexts.0 = Counter32: 0
SNMP-TARGET-MIB::snmpUnknownContexts.0 = Counter32: 0
The snmpTargetAddrTable contains:
SNMP-TARGET-MIB::snmpTargetSpinLock.0 = INTEGER: 0
SNMP-TARGET-MIB::snmpTargetAddrTDomain.'internal0' = OID:
SNMPv2-TM::snmpUDPDomain
SNMP-TARGET-MIB::snmpTargetAddrTAddress.'internal0' = Hex-STRING: 9B
E2 3D 48 00 B7
SNMP-TARGET-MIB::snmpTargetAddrTimeout.'internal0' = INTEGER: 0
SNMP-TARGET-MIB::snmpTargetAddrRetryCount.'internal0' = INTEGER: 0
SNMP-TARGET-MIB::snmpTargetAddrTagList.'internal0' = STRING: internal0
SNMP-TARGET-MIB::snmpTargetAddrParams.'internal0' = STRING: internal0
SNMP-TARGET-MIB::snmpTargetAddrStorageType.'internal0' = INTEGER:
readOnly(5)
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'internal0' = INTEGER:
active(1)
This seems to be the minimum requirement for defining a trap
destination using these tables. There is a lot in these MIBS that only
apply to v3 so some of the OID's may default to acceptable values and
may not need to be defined. To add a second trap destination entry
all three tables must be updated. I added a second trap destination
and it took 21 snmp sets which does seem cumbersome.
Since these MIBS are written for v3 does using these tables in this
manner for a v2c agent violate any standards? Are there any reasons
why I should not do this? One benefit will be that when/if we do go
to v3 we will already have these MIBS implemented.
Vince