|
Please
disregard the second part of this e-mail.....the questions about the SELECT,
FETCH, and MAP information from the tecad_nv6k.cds file. I have found the
correct information in the adapters guide and am gaining a better
perspective. THANKS !!!!!
Absolutely !!! Friday was the day of epiphany....HA!.
This stuff is making soooo much more sense. I've already talked with our
WAN manager this morning about trying to get those devices configured to
send the ifDescr variable with the trap, if they can. And if not,
I'm already exploring using a Perl script to get that information......both
you and Philippe have had the same suggestion.........oh the power you feel
when you have the right information from the right people.....things are
certainly looking UP !!!! You mentioned the possibility of using
$A and $1 as variables in the script used as the "Hidden
Application"....so I am to assume that those variables are valid within the
script I would call since the script would be running withing the "realm" of
the defined trap that it would be working off of ?
As
has been the case with most of the questions I submit to the list, the answers
to this one have also led me down another path that brings up another
question. Within the tecad_nv6k.cds file, I see things like SELECT,
FETCH, and MAP. From what I can gather by just looking at it.....the
SELECT area seems to be an instantiation of a series of numbered
ATTR variables linked to pieces of information from the trap (like
ifIndex, ifDescr, and many others), which are then used in the MAP section to
"map" those variables using $V1, $V2, etc. to specific slots of a TEC
event. I also see the FETCH area, which has numbered statements that
appear to "grab" other information....like "1: IPNAME($AGENT_ADDR)"...so that
this information can also be "mapped" to a slot in the TEC event using $F1,
$F2, etc. as the variable........if this is in fact what it is doing, where is
it fetching this information from ? It appears by the way it's layed out
that it is from somewhere other than the trap itself....so I'm assuming from
NetView. This would be great if it's true, because from that....then I
can populate the hostname slot of the event that gets sent to TEC with a
meaningful name........right now, these "Link UP SNMP trap" and "Link DOWN
SNMP trap" events don't have anything in the hostname field. The do have
the IP address in the adapter_host slot, but that isn't as meaningful to our
Help Desk as would be the hostname.
-----Original
Message-----
From: James Shanks
[mailto:jshanks@us.ibm.com]
Sent: Monday, October 27, 2003 10:04
AM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] trap
DEFAULT FMT
You are on the right track
Brian. You would indeed use the tecad_nv6k.cds to extract and map the
information you want to send to TEC, provided that it is included in the
original trap (usually as a variable). If it is not, then the
next best thing would be to find a way to reconfigure the trap sender so
that it is. If that cannot be done, then you do have other choices in
NetView for Windows, but they involve more elaborate user programming.
You could, for example,
launch a script whenever this trap is received (by configuring Trap Settings
for it as a "Hidden Application"). You would probably need some
scripting language on your Windows box like PERL or REXX to be able to do
everything you want in your script, but if you had that, then you could have
your script query the sender for the ifDesc of that interface using snmpget.
You would pass your script the hostname or IP address of the sender as $A
and the ifIndex as $1, and after you got your answer with snmpget, then you
could issue a trap of your own devising using nvsnmptrap, and include the
ifDesc as a variable. This new trap would be the one you would catch
in the tecad_nv6k adapter to send to TEC, while dropping the old one.
Do you see how that would work?
James Shanks
Level 3
Support for Tivoli NetView for UNIX and Windows
Tivoli Software /
IBM Software Group
|
| Brian Kraftchick
<Brian.Kraftchick@odfl.com>
Sent by: owner-nv-l-digest@lists.us.ibm.com
10/24/2003 04:14 PM
Please respond to nv-l
|
To: "'nv-l@lists.us.ibm.com'"
<nv-l@lists.us.ibm.com>
cc:
Subject: RE: [nv-l] trap DEFAULT
FMT
|
Netview 7.1.2 on Win2K
James,
I can't thank you enough for taking
the time to "pull me back" from the complexity that I was creating for
myself. I did as you suggested and ......voila....we have a meaningful
event....well meaningful to me anyway.
Philippe,
Also excellent
help....especially the last portion of your reply.....upon taking James
advice, I was able to define the trap that was coming and play around with
the description to get it to "mean" something to me. The last part of
your reply referenced being able to also gather something like the ifDescr
value, which would give us the name of the interface in addition to it's
ifIndex integer......this is what I am after next.
Upon further inspection of trapd.log it appears that the traps that
these devices are sending only contain 1 variable....the ifIndex integer
(whose value happens to be 1) only. So, being that I want to also know
the actual name of the interface that is down (ifDescr)....should I look in
the direction of configuring the router's traps to also provide this
information as well (if this is possible) ? If that were possible, my
interest is then to be able to get that information into a slot in a TEC
event...to get that same "meaninful" information there..... vs. just the
vanilla "Link Down SNMP Trap" message without a hostname that it gets now.
James, I think you mentioned this in your e-mail with regards to this
possibly being difficult, if at all possible, on the Windows
platform/version of NetView. I have played around with the
tecad_nv6k.cds file some today and was able to understand somewha! t, the
relationships and structure of how the cds file gets the information and
populates the event with that information......it looked to me like it might
be possible.....so long as the original trap at least provided that
information. Any info here would help a WHOLE lot.....HA !
Well, please reply with any thoughts
either of you, or anyone else might have........I feel like I'm getting
there....slowly but surely....but at least getting there !!!!
Thanks again !
-----Original Message-----
From: James Shanks
[mailto:jshanks@us.ibm.com]
Sent: Thursday, October 23, 2003 6:51
PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] trap
DEFAULT FMT
Relax. You
are making this too hard. Just take a deep breath and look at Trap
Settings. Both bgp and bridge are the same way. They don't use a
vendor specific (1.3.6.1.4.1.x) OID but rather something under MIB-II
(mib-2) "1.3.6.1.2.1.x". You can do the same. Just match what
came in.
Do you see an Enterprise definition for
"1.3.6.1.2.1"? I'll bet not because it
is not an enterprise (it does not describe a vendor with a number assigned
by IANA) so you'll have to invent one. In Trap Settings click the
"New" button for Enterprises. What would you like to call it?
How about MIB-II or MIB-2
since that's what it stands for? It doesn't matter what name you
give it -- that's just an internal organizing convenience. Now define
the trap underneath. Click "New" there too. Then pull down "TrapType"
and click the correct trap. How do we know which it should be?
Part of your SNMP education should include the
fact that the standard define six generic types of traps and one for
vendors to use. They are these:
Cold Start
Generic Type 0
Specific Type
0
Warm Start
Generic Type 1
Specific Type 0
Link
Down Generic Type 2
Specific Type
0
Link Up
Generic Type 3
Specific Type 0
Authentication Failure Generic Type 4
Specific Type
0
EGP Neighbor Loss
Generic Type 5
Specific Type 0
everything else is
vendor-specific
<vendor's OID>
Generic Type 6
Specific Type <any
interger>
So click on Link Down and then define the rest of
the trap any way you want. Pick something other than "Log Only" for
the Trap Category so that it displays in the Event Browser by default.
Then OK and you are done.
Now, to answer your questions. You are
getting ahead of yourself. NetView did not recognize your LInk Down
trap because he did not have an enterprise OID defined for "1.3.6.1.2.1" because
that is not a standard enterprise OID of the sort 1.3.6.1.4. 1.x. It's
just that simple. Now you have defined one and the default wrapper
will disappear.
What information can you send to TEC about this?
Well, that depends on whether there are any additional variables
included with the trap. If there are, then you are in luck, if not, on
Windows you are pretty much out of luck, since the Windows adapter doesn't
permit much customization. But we can discuss that at another time.
As for map updates, on Windows that too is
limited. Generally speaking, netmon owns all the objects shown on the
map. All of then. He discovered them and he put them there.
He's the one who ultimately turns things colors by updating the
databases and sending notice to ipmap (who owns all the symbols on the map)
to make the color what it is. Changing colors on receipt of your own
traps, rather than letting netmon do it on his regular polling cycle, is
rather a complex undertaking. We can discuss that in another thread,
at another time, too.
But it would be far better
to adjust the polling cycles for these devices so that they are shorter and
netmon is made aware of their problems more frequently, than to try to build
in more overhead by constructing an elaborate mechanism to change object
colors on the map a few seconds faster. Remember the default polling
cycle for netmon is every 5 minutes. He's checking every interface in
your network every five minutes. If that's not soon enough, I'd
lower it for specific devices. You just alter the SNMP
options.
James Shanks
Level 3 Support for
Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software
Group
|
| Brian Kraftchick
<Brian.Kraftchick@odfl.com>
Sent by: owner-nv-l-digest@lists.us.ibm.com
10/23/2003 05:38 PM
Please respond to nv-l
|
To:
"NVList (E-mail)"
<nv-l@lists.us.ibm.com>
cc: Lisa Boles
<Lisa.Boles@odfl.com>
Subject: [nv-l] trap DEFAULT
FMT
|
NetView 7.1.2 on
Win2K
Okay....James, you mentioned before that when I see a
trap in trapd.log specified as "DEFAULT FMT" that this means that NetView
did not know how to interpret the trap that was received and put a default
"wrapper" around it and logged it and placed it as an event. That's
what I've been seeing for some time now with the traps that I am receiving
from the Bay Networks (Nortel) Advanced Remote Node (ARN) routers. We
have one of these routers in our test lab with a Frame Relay connection to
our office, and a configured internal ethernet interface for that router's
LAN. When I pull the cable on the ethernet interface, the router
produces a trap and sends it to NetView. According to our consultant,
who configured the router to send a trap when something like that happens,
the trap being sent is not an Enterprise specific trap, and is
simply a mgmt.mib-II.x.x.x .....link down type trap. Thi! s is where
my problem lies..! ...if the trap isn't Enterprise specific
(wellfleet), but is of mgmt.mib-2.x.x.x type, how come NetView does not know
what it is ? When I see the event in the Event Viewer, I do see what
"node" it came from, which is meaningful, but the description field states
"DEFAULT FMT: mgmt.mib-2 (1.3.6.1.2.1) generic:2 specific:0", and the
Enterprise column shows "1.3.6.1.2.1". All of this I assume is because
as James stated, NetView doesn't know what to do with the trap.........if it
doesn't know....how does it know that this was a "Link Down" type of trap?
Does "generic:2" mean link down ???? And most importantly...when
these are received, as I mentioned before, nothing in the NetView map gets
updated....the status of that device (which is managed) should go to yellow,
meaning that it has a problem...mainly, an interface down. (Right now
I have turned off all polling s! o that I can work only wit! h traps and
KNOW what is happening a! nd why.. .we are intendi! ng on re lying on these
and other backup devices to send traps when their are issues vs. just
relying on polling). In our situation, we need to know exactly when
these devices have problems, vs. waiting for a polling period to check the
device. We do have the TEC adapter installed, but when the events
above get there, they are very "vanilla"....stating simply that there is a
Link Down.....drilling down into the attributes of the TEC event does tell
you which device (ip address) sent the trap....but there's nothing in the
"Host" attribute.....What the ultimate goal is, is to have that Event in TEC
show up with the "message" attribute giving a Link Down message with the
exact interface, and at least the router's IP address as the host.
Back on the NetView server, I understand that in the "Trap Settings" I
can configure the event description, and I understand how to do that.....but
WHAT trap definition wou! ld I be editing? &nbs! p;the Link Down trap
under the NetView enterprise ???????
Brian Kraftchick
Network Administrator
Old Dominion Freight Line
Ph: (336) 822-5938
Fax: (336)
822-5149
E-mail: brian.kraftchick@odfl.com
Web Site: www.odfl.com
|