|
Good Morning,
Yes, you are correct, the ctrl-Ms were a result of FTP'ing
from WIN to AIX w/o using ACSII mode. I removed RFC-1212 and RFC-1155-SMI,
re-concatenated the files and had an error on RFC-1215. I looked at
RFC-1215 and it indicated that is also does not contain definitions but macro's
like RFC-1212 so I removed this from the list also and re-concatenated, ran
mib2trap. Here are the messages. Are these normal and what do they
mean?
# mib2trap CISCO-PORT-STORM-CONTROL-MIB.in
CISCO-PORT-STORM-CONTROL-MIB.sh
Warning: The mib description doesn't seem to be consistent. Some nodes couldn't be linked under the "iso" tree. These nodes are left: Left-over node ifTestOwner ::= { ifTestEntry 6 } (133) Left-over node ifTestCode ::= { ifTestEntry 5 } (132) Left-over node ifTestResult ::= { ifTestEntry 4 } (134) Left-over node ifTestType ::= { ifTestEntry 3 } (1) . .
.
. text
removed
.
.
.
Left-over node ifStackTable ::= { ifMIBObjects 2 }
(14)
Left-over node ifXTable ::= { ifMIBObjects 1 } (14) Left-over node ifTableLastChange ::= { ifMIBObjects 5 } (139) Enterprise object id not found for trap linkDown, (6,3).Enterprise object id not found for trap linkUp, (6,4).# Also the resulting script:
more CISCO-PORT-STORM-CONTROL-MIB.sh
# # This file generated by command: mib2trap CISCO-PORT-STORM-CONTROL-MIB.in CISCO-PORT-STORM-CONTROL-MIB.sh # on Tuesday, Apr, 14 2009 at 07:26 AM # # # NOTE: Running this script will add or update these trap definitions in /usr/OV/conf/C/trapd.conf. # The Category field (-c ) has been preset. You should decide what it should be. # # You may change it now by editing this script, or later by using the GUI (Options ... Event Configuration). # Use "LOGONLY" if you do not want to see these traps in the Event windows or have them forwarded to the TEC server. # Use "Status Events" or another category defined in trapd.conf to have them displayed or forwarded to TEC. # # See the man pages on addtrap, xnmtrap, and trapd.conf for more information. # # /usr/OV/bin/addtrap -l linkDown -g 6 -s 3 \ -n snmpTraps \ -o A -c "LOGONLY" -t 0 \ -S 1 \ -T \ -D "A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." \ -e linkDown \ -F '$E $G $S $# args: $*' /usr/OV/bin/addtrap -l linkUp -g 6 -s 4 \ -n snmpTraps \ -o A -c "LOGONLY" -t 0 \ -S 1 \ -T \ -D "A linkUp trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." \ -e linkUp \ -F '$E $G $S $# args: $*' /usr/OV/bin/addtrap -l cpscEvent -g 6 -s 1 \ -n cpscNotificationsPrefix -i 1.3.6.1.4.1.9.9.362.0.1 \ -o A -c "LOGONLY" -t 0 \ -S 1 \ -D "This notification is sent by the implementation when a storm event occurs on an interface with respect to a particular traffic type." \ -e cpscEvent \ -F '$E $G $S $# args: $*' Thank you very much for your help as
always,
Kevin Sperry From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of James Shanks Sent: Monday, April 13, 2009 7:26 PM To: Tivoli NetView Discussions Subject: Re: [NV-L] Mib2trap help Good catch, Leslie. I assumed that the ctrl-Ms were the result of ftp'ing the file from UNIX to Windows without using ASCII mode and that the UNIX copy did not have them. But in any case, removing all of RFC-1212 should get rid of them. So I went for the elephant rather than the mouse. If the resulting file still has ctrl-Ms in it, then they should be removed to prevent unpredictable results. Our MIB parsers get one character at a time, and ctrl-M is a character as surely as the letter "Z", so the parser will see "END^M" just like it sees "ENDZ", as a different keyword from "END" and therefore an error. I guess the point I was trying to make in a round-about way is that many users, once the notion of a concatenated input file is explained to them, try to build one that contains every other MIB mentioned in the IMPORTS clause of their target one, which is not necessary and sometimes even counter-productive. mib2trap will tell you if it cannot resolve something, and most of the time, that will be in a MIB that comes from the same vendor as the target and not an RFC. The parsers already know about every basic MIB construct in SNMPv1 and SNMPv2. It's usually only the vendor added defs that they don't know about. I myself never build a concatenated file unless mib2trap tells me that something is left undefined, and then I go looking in the IMPORTS section to see where that might be. James Shanks Tivoli Network Availability Management Level Three Network Availability Management Tivoli Software, IBM Corp 1-919-224-1642 | T/L 687-1642 | ITN 26871642
James, does he have to remove the ^M things from the file? Or are they supported now? This is on AIX, I think. Cordially, Leslie A. Clark IT Services Specialist, Network Mgmt Information Technology Services Americas IBM Global Services (248) 552-4968 Voicemail, Fax, Pager
Remove RFC 1212 from your concatenation. It is not needed and cannot be parsed any way. Ditto with RFC 1155. These RFC's contain macros which define the basic parts of the MIB tree. And macros cannot be parsed by mib2trap. It will not let you re-define it components, only use them. Generally speaking no RFC lower than 1213, which defines MIB-II, can be or needs to be included in your concatenation. James Shanks Tivoli Network Availability Management Level Three Network Availability Management Tivoli Software, IBM Corp 1-919-224-1642 | T/L 687-1642 | ITN 26871642  "Sperry, Kevin"
<Kevin.Sperry@us.ngrid.com>
Hello again, With NetView 7.1.5 on UNIX, trying to run mib2trap on concatenated file. I am receiving the following… # mib2trap CISCO-PORT-STORM-CONTROL-MIB.in
CISCO-PORT-STORM-CONTROL-MIB.sh Not sure why the error. Below is part of the file. RFC-1212 ends at line 2941. +2938 -- ipAddress^M Any help or documents would be greatly appreciated. Thank you,
Kevin Sperry ******************************************************************************** ******************************************************************************** _______________________________________________ NV-L mailing list NV-L@lists.ca.ibm.com Unsubscribe:NV-L-leave@lists.ca.ibm.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only) |
_______________________________________________