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: Jane Curry <jane.curry@skills-1st.co.uk>
Date: Tue, 24 Jan 2006 10:14:24 +0000
Delivery-date: Tue, 24 Jan 2006 10:15:23 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <20060123235552.GQ9365@localhost.localdomain>
References: <20060123203641.GB2035@localhost.localdomain> <OFCACCD6F5.7C57D288-ON852570FF.007EC97D-852570FF.00804C3D@us.ibm.com> <20060123235552.GQ9365@localhost.localdomain>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
User-agent: Mozilla Thunderbird 0.5 (X11/20040208)
Hi Michael,
I sense (and have shared) your frustration over documentation about NetView TEC adapters, but please remember we are all volunteers here - and that includes James!

If you really are seeing hostnames in origin slots then I would suggest that that is a job for support. I don't think I have ever seen that happen, unless I have edited tecad_nv6k.cds to produce that effect. Any chance that you do have another copy of tecad_nv6k.cds that is being used and has had the IPADDR function removed from in front of the first FETCH statement??

The IPADDR function is supposed to return the IP Address of a hostname (fairly obviously). There is also an IPNAME function (again undocumented) which does the reverse - takes an IP address and does a lookup to return a hostname. There used to be an issue with IPNAME prior to 7.1.4 FP1 but I have not seen issues with IPADDR.

Here is the section of my tecad_nv6k.cds for interface down and it is definitely populating addresses into the TEC origin slot and names into the hostname slot (as I have DNS in place).

CLASS  TEC_ITS_INTERFACE_STATUS
 SELECT
   1: ATTR(=,$ENTERPRISE) , VALUE(PREFIX, "1.3.6.1.4.1.2.6.3" ) ;
   2: $SPECIFIC = 58916866 ;
   3: ATTR(=, "nvObject" ) ;
   4: ATTR(=, "nvEventDescr" ) ;
   5: ATTR(=, "nvApplNbr" ) ;
   6: ATTR(=, "VB_8") ;
   7: ATTR(=, "VB_7") ;
 FETCH
   1: IPADDR($V3);
   2: IPADDR($V7) ;
 MAP
   origin = $F1 ;
   hostname = $V3 ;
   msg = $V4 ;
   category = $V5 ;
   ifstatus = 1 ;   # UP
   ifname = $V6 ;
   hostaddr = $F2 ;
   nvhostname = $ADAPTER_IP ; # Required for ALL TEC_ITS events
END

Cheers,
Jane


Michael D Schleif wrote:

* James Shanks <jshanks@us.ibm.com> [2006:01:23:18:2hostIPaddress1: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



--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2006 Jane Curry <jane.curry@skills-1st.co.uk>.  All rights 
reserved.


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

Archive operated by Skills 1st Ltd

See also: The NetView Web