| > We are also trying to receive standard traps from the Cisco like
> linkUp, linkDown, etc., but our sink is not receiving any events.
>
> We have set up the Cisco to trap back to our mcc station, and have
> tried to generate traps by brining unused interfaces up and down.
> One of our questions is: "Does an interface have to have its
> protocol up to generate a linkUp trap, or can it be just
> administrativly up?"
An unused Ethernet port makes a dandy 'trap generator'. Put an Ethernet
loopback plug on it if you have no gear on it. Turning it off/on via
DECmcc or cisco config commands will work just fine. Turn off interface,
get LinkDown trap. Turn on interface, get LinkUp trap.
>The other is, how can we tell if SNMP packets are getting to our station
>without a sniffer or some other packet grabber?
$! this will display 1 trap and quit
$ MANAGE/ENT GETEVENT SNMP * ANY CONFIG EVENT
$! this will display traps for 30 minutes
$ MANAGE/ENT GETEVENT SNMP * ANY CONFIG EVENT, FOR DURATION 0:30:00
$! this will display traps for 30 minutes to output file
$ MANAGE/ENT GETEVENT SNMP * ANY CONFIG EVENT, FOR DURATION 0:30:00, -
TO FILE TRAPS.TXT
The above commands assume that DECmcc/UCX is minimally working... if DECmcc
is not working, then you will get nothing.
Also, you may get 'enterpriseSpecific' traps each time you close a Telnet
session into the Cisco console for that box.
Lee
|
|
re: .0
> 1)
> We are attempting to compile the Cisco MIB extensions for traps
> above and beyond MIB-II standard traps, but having some trouble
> getting the file through the MTU.
>
> We've appended the trap MIB definition file to the cisco_mibdef.txt
> supplied with mcc. This is the one that says it is hacked by Mr.
> Bemis? When the MTU gets to the Cisco specific traps, it chokes and
> says that it sysUpTime has not been defined. The log files can be
> found in NYOS01""::cisco-mcc-problems.txt
You are facing 2 MTU restrictions :
1/You are not allowed to define standard traps in a private mib. All this traps
are pre-loaded in DECmcc so you'd be able to receive standard traps from
cisco.
If a vendor re-defines a standard trap in order to add more variables
( RFC 1157 authorizes it ), forget it ! SNMP AM cannot handle any extra
variables returned in the traps.
2/When defining private traps, you cannot use variables from mib-II : these
variables should be commented out.
For example in your case :
tcpConnectionClose TRAP-TYPE
ENTERPRISE cisco
VARIABLES { tslineSesType,
--tcpConnState,
loctcpConnElapsed,
loctcpConnInBytes, loctcpConnOutBytes, tsLineUser }
DESCRIPTION
...
Note that tcpConnState from mib-II is commented out.
Of course, the field 'tcpConnState' is ignored when the trap is received.
> 2)
> We are also trying to receive standard traps from the Cisco like
> linkUp, linkDown, etc., but our sink is not receiving any events.
>
> We have set up the Cisco to trap back to our mcc station, and have
> tried to generate traps by brining unused interfaces up and down.
> One of our questions is: "Does an interface have to have its
> protocol up to generate a linkUp trap, or can it be just
> administrativly up?" The other is, how can we tell if SNMP packets
> are getting to our station without a sniffer or some other packet
> grabber?
Beware that the source address from the trap PDU should be registered in DECmcc
if you want to handle traps. Let's assume that 2 path are available from the
cisco : then the router has to be registered twice in MCC.
If you are running DECmcc on Ultrix, you can easily track SNMP PDUs by starting
your snmp daemon in debug mode. On VMS you can check UDP counters ( something
as ucx>show protocol udp /cont ) assuming that no other applications using
udp is running at the same time.
I agree with .1 that tcpConnectionClose is the easyest private trap to generate
on cisco boxes.
Guy.
|