nv-l
[Top] [All Lists]

Re: [nv-l] origin: NV -> TEC ???

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] origin: NV -> TEC ???
From: Michael D Schleif <mds@helices.org>
Date: Mon, 23 Jan 2006 17:55:52 -0600
Delivery-date: Mon, 23 Jan 2006 23:56:20 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <OFCACCD6F5.7C57D288-ON852570FF.007EC97D-852570FF.00804C3D@us.ibm.com>
Mail-followup-to: nv-l@lists.us.ibm.com
References: <20060123203641.GB2035@localhost.localdomain> <OFCACCD6F5.7C57D288-ON852570FF.007EC97D-852570FF.00804C3D@us.ibm.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
User-agent: Mutt/1.5.9i
* 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 . . .
--

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web