Conference azur::mcc

>> I would like to have the ability 'do this' using MCC.  Perhaps the auking
>> could result in data being brought into the mir for pa work. 
 
Hi Tom,

If the PA module isn't up for the task in the proper time frame (as you know
this is an ASAP application) then an option of "exporting" the data to an
external DB rather than the MIR (for PA) might be a good option. I would
think the procedures to be written to produce the graphs/reports would
be relatively simple from there. Is there any chance of getting this into
MCC??

best regards,
brad...

    

I received the following reply from Al Zavalick today.
    -----------------------------------------------
From:	ASD::ZAVALICK     "Alan Zavalick DTN 381-2847" 11-SEP-1991 13:57:01.30
To:	CTHQ3::WICK
CC:	ZAVALICK
Subj:	RE: requirement for latency reports/graphs

Tom,
I've asked Helen Hower of my team to respond to just what can and can't 
be done with the results of the DA diagnostics (including PING) in V1.2

As you correctly interpreted, EXPORT will *not* be able to capture the
output at least not in V1.2

The whole strategy around PING needs addressing I feel. We feel it really
belongs as a function in the SNMP AM even though it doesn't rely on SNMP
protocol. Then, the SNMP Global Entity might be able to model some 
'synthesized' attributes like turnaround times from PING requests.
Once these were attributes on an entity, the PA might be able to create
some statistics around them, IMPM might be able to graph them, and EXPORT
could archive them to relational databases.

Thanks,
Alan

P.S> I think your proposal to capture this kind of info is right on target!
    

re - .1

>As you correctly interpreted, EXPORT will *not* be able to capture the
>output at least not in V1.2

Why the hell not ?!?!
If it gets sent back over the mcc_call interface, then what reason is there
that the AM dictionary data couldn't be augmented to support Historian/Export?

/doug

    The TCP/IP DA does modify the SNMP global entity but modifies it for
    diagnostics in the form of directives and responses. PING is one such
    directive. It is not currently possible to export or record the
    contents
    of a response. If you (-.1) reread my response to Tom posted in .-2
    you can see a proposed way of getting PING funtionality to be available
    for Alarms, Export, IMPM graphs(possibly), and PA statistics. I believe
    it is limited to being returned on the results of a SHOW to get it
    integrated into the MIR. Now whether the TCPip DA FM PING could be 
    dispatched to 
    as a result of a request for an as yet unspecified attribute on the
    SNMP entity I don't know. We could then possibly return the attribute
    e.g. "turnaround-time" when/if we could determine it.
     I'll ask others (Helen??, others) to speculate
    on how it might be done.
    
    -Alan

>>As you correctly interpreted, EXPORT will *not* be able to capture the
>>output at least not in V1.2
>Why the hell not ?!?!

Well, basically, because only an entity's defined and stored attributes can be 
recorded by the historian and exported  None of the diagnostic results 
(including ping) are stored as "attributes" of the snmp entity; they are simply 
passed back through the call interface via the cvr and out_p, usually to be 
displayed by one of the PMs.  

Anyway, to continue:

What can be done with DA for v1.2:
  -results can be written to a log file (using PM functionality), and further 
   processed outside MCC via scripts, command procedures, or such.
  -TCP/IP DA can be invoked via mcc_call(_function) interface, and cvr and 
   results in out_p can be interpreted and further processed by a program or
   another FM.
  -(wrt ping) you can determine whether the target host is alive.  There's some
   further information given if ping results in "unexpected" ICMP responses.

What can't be done:
  -results are not stored as attributes of the snmp entity.  This means that 
   they cannot be used by historian, exporter, or alarms.
  -(wrt ping) statistics and latency cannot be determined; we aren't calculating 
   them in the code doing the ping.

Yes, I agree, too, that PING-derived attributes would be most useful, even 
though they would be of a different source than the other MIB-specific 
attributes of an SNMP entity.  This discrepency needs to be resolved before 
long, so this information can be available for, well, assisting in diagnosing
network problems by analyzing historical trends and/or generating alarms.

Question: could the SNMP trap/event info (planned for v1.2) be used to provide 
some of the functionality that you need?

If there is a real need to store this stuff, Helen isn't it possible
that you add an entry point (NOT and msl definition) for the show
directive that dispatches to the ping entry point. It would also mean that you
have the avbility to encode the results of the ping in two formats (based
upon how you were called) in an attr list or as response arguments 
(means an extra set of put cons on the list, and new attr definitions 
for the values -- display=false will stop them from showing at the
UI on a set or show).


I said it wasn't real kosher, but if we are trying to meet a functional
requirement that isd this impoartant we shoudl consider all options.

Sounds interesting...  Wouldn't someone still need to define a ping-status 
attribute, to be invoked with?  (and, possibly, ping-latency, though that'd
require further code changes within DA to calculate it)

Isn't spec'd as a functional requirement, but would certainly seen to help meet 
a real user's needs...

Will talk to you more about it offline.
		Helen

Simple PING functionality will be provided by the SNMP AM for DECmcc V1.2.
We've implemented it two ways.  As a TEST directive and as status attribute.

DECmcc (T1.2.1)

MCC> test snmp myunix

SNMP myunix
AT 27-SEP-1991 08:19:33

Test successful.

MCC> show snmp myunix all status

SNMP myunix
AT 27-SEP-1991 08:19:55 Status

Examination of attributes shows:
                         ipReachability = up
MCC>


The status attribute provides Recording, Exporting and Alarming capabilities.
I realize that this only solves part of the problem stated in .0 since it
dosen't address the statistics and latency questions.  As stated earlier, turn 
around time on the PING would have to be defined as an additional "synthesized"
attribute, calculated and returned.  Well worth some thought and discussion.

-Dan

fwiw - The Example FM implements the PONG directive.  This directive calls
the Sample AM and times how long it takes to retrieve the Identifer Attributes
from the Phase 4 Node (executes: SHOW SAMPLE <node> ALL IDENTIFIERS).  The
command line is:  PONG SAMPLE <node>

The source code will ship with the v1.2 DECmcc toolkit, and is written as
a Generic FM -- well, except maybe some comments  :) 

I, personally, would like to see such functionality provided as part of
the DECmcc Application Architecture and implemented as a Generic FM; the Example
FM is a great start!

(Also, the Example FM has an 'Acceptable Response Time' attribute which defines
how long to wait for the response - and posts an Event if a Time Out occurs).

/Keith

re:                       <<< Note 1479.8 by DANZO::CARR >>>
                    -< PING to be part of SNMP AM for V1.2 >-

Simple PING functionality will be provided by the SNMP AM for DECmcc V1.2.
We've implemented it two ways.  As a TEST directive and as status attribute.

	There are 2 fundamental 'attributes' I think:  ipreachability (pingness)
	and SNMPness.  Is the user going to be able to tell that this
	system is one or both?  What does 'test successful' mean?

	Mike

Currently:

 "Test Successful" means that the entity responds to ICMP echo.

 Status Attribute ipReachability (SHOW SNMP id ALL STATUS) indicates
   IP reachability (ping).

 SHOW SNMP id ALL IDENT indicates pingness.

 REGISTER SNMP ... succeeds if entity responds to ICMP echo (otherwise
   it is "partially registered").

 Response (or lack thereof) to SHOW ALL CHAR|COUNT|STATISTICS indicates
   SNMPness.

Current behavior allows us to display TCPIP Icons on the map for entities
not supporting SNMP and to reflect their reachability on the map (via
alarm rules, etc).

A status attribute like SNMP Reachability might be nice to add...

I thought it might be worth entering the manual pages for a version of ping 
which we have running here in TAY2.  This version provides some of the 
statistics which this note has been mentioning. If this version was included in
MCCV1.2 perhaps much of the work in collecting statistics would be accomplished
without any/much work to MCC.

Tom
                                                                     ping(8)



   Name
     ping - send ICMP ECHO_REQUEST packets to network hosts

   Syntax
     /etc/ping [ _o_p_t_i_o_n_s ] _h_o_s_t [
_d_a_t_a_s_i_z_e [ _n_p_a_c_k_e_t_s ]]

   Description
     The DARPA Internet is a large and complex network of hardware connected
     together by gateways.  The _p_i_n_g command utilizes the ICMP protocol's
     mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a
     host or gateway.  ECHO_REQUEST datagrams (pings) have an IP and ICMP
     header, followed by a struct timeval, and then an arbitrary number of
     pad bytes used to fill out the packet.  The length of the default
     datagram 64 bytes, but this may be changed using the command-line
     option.

     Typing ``ping _h_o_s_t'' without any options will either
report ``_h_o_s_t is
     alive'' or ``no answer from _h_o_s_t''.  To get more statistics use the -l
     option or one of the other options.

     When using _p_i_n_g for fault isolation, it should first be
run on the local
     host to verify that the local network interface is up and running.
     Then, hosts and gateways further and further away should be pinged.  The
     _p_i_n_g command with options sends one datagram per second and prints one
     line of output for every ECHO_RESPONSE returned.  No output is produced
     if there is no response.  If an optional _n_p_a_c_k_e_t_s
is given, only that
     number of requests is sent.  Round-trip times and packet loss statistics
     are computed.  When all responses have been received or the program
     times out with _n_p_a_c_k_e_t_s specified, or if the
program is terminated with
     a SIGINT, a brief summary is displayed.

   Options

     -d   Turns on SO_DEBUG flag on the socket.

     -l   Gives more statistics than if _p_i_n_g is used without options.  Long
          output.

     -r   Bypasses the normal routing tables and sends directly to a host on
          an attached network.  If the host is not on a directly-attached
          network, an error is returned.  This option can be used to ping a
          local host through an interface that has no route through it.  For
          example, after the interface was dropped by _r_o_u_t_e_d(8c).

     -v   Lists ICMP packets other than ECHO RESPONSE that are received. Ver-
          bose output.

   Restrictions
     This program is intended for use in network testing, measurement, and
     management.  It should be used primarily for manual fault isolation.
     Because of the load it could impose on the network, it is unwise to use
     _p_i_n_g during normal operations or from automated scripts.



                                                                            1






   ping(8)


   See Also
     netstat(1), ifconfig(8c)






















































   2