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

[Jane Curry <jane.curry@skills-1st.co.uk>]

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.