I am implementing the CISCO-EPM-NOTIFICATION-MIB and field cenAlarmDescription (1.3.6.1.4.1.9.9.311.1.1.2.1.16249) contains for than 249 characters. Netview is truncating this field. Is there a setti
Depends on where this occurs. NetView for UNIX or Windows? Truncating it where? In the Event display? In trapd.log? In TEC? 249 is an odd number. The maximum length of a varbind that trapd will suppo
This is in Netview AIX. The trap is truncated in the event display and the trapd.log. It is being assumed that Ciscoworks is sending the full value. Ciscoworks is directly mailing the network admin a
Well, you can turn on the "hex dump all packets option" for trapd, so that he runs with the -x option, and then toggle the trace on and off from the command line with "trapd -T". The trapd.trace will
This is what cisco should be sending. .1.3.6.1.4.1.9.9.311 42.116.24.30 6 2 '' .1.3.6.1.4.1.9.9.311.1.1.2.1.16 octetstring "Unresponsive::Component=s0986-cr-s2950-1.ns.ctc;Type=SWITCH;Description=Cis
Send an event command. Just "event" will do, and look again. If dev109.cs.ctc is your NetView box, and you send the snmptrap, and then immediately go look for it in trapd.log, then you may not see it
I had some time while awaiting a build to run, so I took a closer look at your snmptrap. I found a number of issues with it, assuming that it was a cut-and paste of what you actually tried to send. /
Hi James, We are using 7.1.3 as well, I assume that the 512-byte limit is the problem. The sendtrap works fine until I send it with the full length string for .1.3.6.1.4.1.9.9.311.1.1.2.1.16 Sean Law
The 512-byte limit per varbind applies to 7.1.3 and all releases back to 6.0.3. Before that some processes observed it, while other did not, which left them vulnerable to the kind of attacks that CER
Hmmm, I will have to put trace on and retest. The traps are coming in from Ciscoworks with that field truncated, it's just the one I formed myself that throws the error. Sean Lawrence Systems Automat