* James Shanks <jshanks@us.ibm.com> [2006:01:23:18:21:19-0500] scribed:
> You are right the NetView books don't go into detail about the TEC adapter
> files. It was assumed that when NetView became part of TEC, anyone doing
> TEC forwarding would already be familiar with how TEC and it's adapters
> functioned. The information development folks declined to replicate
> similar information found in the TEC Event Adapter Guide. Just take a
> look at the OpenView adapter section and you'll see most of the same stuff.
OK. That is as it should be.
> When you see an attribute in the CDS file defined like this
> ATTR(=, "nvObject" );
> the quoted text is a name which is being used in place of an OID. The OIDs
> are defined in the tecad_nv6k.oid file:
> "nvObject" "1.3.6.1.4.1.2.6.3.1.1.3"
>
> These are the variables discussed in the Appendix of the of the NetView
> users Guide
> "nvApplNbr" "1.3.6.1.4.1.2.6.3.1.1.2" varbind 1 an integer
> representing the originating NetView process
> "nvObject" "1.3.6.1.4.1.2.6.3.1.1.3" varbind 2 hostname
> "nvEventDescr" "1.3.6.1.4.1.2.6.3.1.1.4" varbind 3 formatted
> description of the event
> "nvEventInfo" "1.3.6.1.4.1.2.6.3.1.1.5" varbind 4
> additional information, typically timestamp, object id number from the
> NetView database
> "nvEventOptInfo" "1.3.6.1.4.1.2.6.3.1.1.6" varbind 5 fixed keyword
> "openview"
<snip />
Yes, I know. Hence my previous request for the MIB so I can know to
what those OID's refer ;>
> A typical TEC event usually looks like this:
> TEC_ITS_NODE_STATUS;source=NV6K;sub_source=NET;origin=9.27.144.151;adapter_host=jshanks1.raleigh.ibm.com;hostname=ALBERT-T-30.raleigh.ibm.com;msg='Node
> Down. ';category=2;nodestatus=2;nvhostname=9.27.131.176;END
Yes, I know. I have been doing TEC work for over ten (10) years.
> origin should be the IP address of the host the trap is about;
<snip />
EXACTLY!
The origin slot values with which I am struggling contain hostname
labels (e.g., ALBERT-T-30.raleigh.ibm.com .)
> If yours don't look this way, then their is a good chance you still have
> some name resolution issues.
How do you figure?
Before name resolution "enhancements", ALL network objects (e.g.,
routers, switches, &c.) appeared as four (4) octet IP addresses. At
that time, the origin slot contained same thing.
NOW, there is NO IP address to be had, in these specific instances; with
the short hostname (as opposed to FQDN) appearing in BOTH hostname AND
origin slots !?!?
If this is a "name resolution issue", HOW in heavens name does THIS
function work?
IPADDR($V3)
Correct me if wrong; but, it is taking this:
3: ATTR(=, "nvObject" );
and processing it through an UN-documented function:
IPADDR()
and coming up with a name, a label; but, NOT an IP address.
In fact, since this obtains:
hostname = $V3;
it follows directly that this is ALSO true:
IPADDR(hostname) == hostname
Again, what am I missing?
NOTE: ALL of my examples are cut-pasted directly from the active CDS
file in /usr/ov/conf/.
Thank you, for your attention to this matter.
> HTH,
>
> James Shanks
> Level 3 Support for Tivoli NetView for UNIX and Windows
> Tivoli Software / IBM Software Group
>
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
signature.asc
Description: Digital signature
|