Conference azur::mcc

> I've read note 2242, which seems to be the latest discussion of how to setup
> and capture notification events from a Phase V node.  Are there any other
> pointers or descriptions of how to do same?

There are several other notes more recent on the subject.  In particular
note 3359.  You will want to take heed to 3359.4 - 3359.6.

> Is the OSI users guide for DECmcc the correct place to look for setup help?

  Yes, as well as the release notes and the WANrouter documentation.

> I've run the router configurator to allow it to point to MCC_DNA4_EVL as
> its OUTBOUND SINK and have indicated that the node running DECmcc is to
> receive the events.  

I hope this is a type-o.  You want to send events to the MCC_DNA5_EVL.


	-- John

Thanks to .1 for the additional pointers.

I"ve tried to point to both DNA5 and DNA4 w/o any results.

I'll put it back to DNA5 and do some more checking.

Al

    > I"ve tried to point to both DNA5 and DNA4 w/o any results.
    
    If your router is DECnet phaseIV, you must send the events
    to the MCC_DNA4_EVL via the procedures stated in the
    documentation for that sink.
    
    If your router is DECnet phaseV, you must send the events
    to the MCC_DNA5_EVL following the procedures listed for that
    sink.  The two sinks have different setup procedures.
    
    You can not expect a PhaseIV sink to understand PhaseV events
    or vise versa. They speak very different protocol.
    
    John
    

Question.....given the fact that this is a WANrouter 500 setup as a Phase IV
level I router, does this mean that Phase IV events will be generated even
though it is using CMIP for management protocol?

The reason I ask is that I tried to purge the Phase V definition in MCC and
re-register it as a Phase IV entity.  This generated an error in that MCC
could not talk to the router....some message about incorrect protocol.

At this point, I'm not even seeing events generated on the local system console,
so I'm assuming that I still don't have the router setup correctly.

According to 3359.4,5,6, depending on how the router was setup and whether or
not you are using DNS (I am not), then the SINK END USER and SINK ADDRESS
fields must be used correctly.

I've configured the router not to use DNS, and to sink events to my DECmcc
systems Phase IV DECnet address of 36.1.  The problem is that I can't get
MCC to take the SINK ADDRESS.  I've tried the following command:

MCC> CREATE NODE LOCAL_NS:.ddcrt1 EVENT DISPATCHER OUTBOUND STREAM DDCRT1_EVL

MCC> SET NODE LOCAL_NS:.ddcrt1 EVENT DISPATCHER OUTBOUND STREAM DDCRT1_EVL -
	SINK ADDRESS = 36.1  (also tried w/o the "=").


The iconic map interface doesn't appear to allow entry of the SINK ADDRESS field.

If I ask for the routers ATTRIBUTES, a long list of parameters comes back for
ADDRESS.  Which of these parameters am I supposed to enter?

Thanks,
Al

> Question.....given the fact that this is a WANrouter 500 setup as a Phase IV
> level I router, does this mean that Phase IV events will be generated even
> though it is using CMIP for management protocol?

No.  WANrouter  is  always a Phase V router.  Always.  And so it always uses
Phase  V management and Phase V event logging.  What you have set up is that
it  should use the same routing algorithm that Phase IV used when talking to
other routers.  That doesn't make it into a Phase IV router.

I know  this  sounds  silly but I would recommend reading the DECNIS release
notes  -- they have some information on event logging which is equally valid
for      WANrouter      (500/100).      You     can     find     them     in
MARVIN::CBN$KITS:[NIS011.LINE_DOCS].

If you  have  used  the  configurator to set up the event stream (to a node)
then  it  will have put a SINK ADDRESS in the script.  SINK ADDRESS *always*
overrides  SINK  END  USER  (in other words, if there is a SINK ADDRESS then
SINK  END  USER  will  be  ignored  completely).   You have to edit the SINK
ADDRESS  in  the  script  to  change  the part that says "NUMBER=82" to read
"NAME=MCC_DNA5_EVL".

Graham

    Thanks Graham.  I had prepared an answer but it looks like
    you beat me to it!  I like yours better anyway :^)
    
    /jp

Thanks Graham,

My understanding of the WANrouter was as you described, but wanted a sanity
check.

I read over the NIS release notes and have had some success generating events
but had to point the "NAME=" field to "NAME=MCC_EVL_SINK" as in the NIS
release notes.....slight correction to your reply in .5.

I've been trying to generate some events by enabling and disabling
the DDCMP port as long as it is still not physically connected, but can't
get this to generate any events.

Can anyone suggest any other commands or sub entities to manipulate that would
also generate events for test purposes.

I do have a notification event for all classes of NODE * enabled and they are
set to pick up "events any".

Al

    MCC> TEST NODE x EVENT DISPATCHER
    
    should generate a testevent.

The TEST   EVENT   DISPATCHER  directive  which  John  mentions  in  .8  was
specifically  designed  for  that  very  reason.   I  am  fairly  sure it is
documented  in  the  section  on  the  Problem Solving Guide that deals with
setting up event logging!

Graham

t sounds as though we, Digital, are really not there yet with regard to
capturing notification events, or should I say capturing significant
notification events and taking proper action with same.

I suspect it is really a question for the MCC folks, but in talking with
John Purretta last week, he showed me how to turn on some additional tracing
from DECmcc to make certain that I was capturing events in DECmcc.  I was,\
infact able to capture a series of events as reported by the router.

However, I am disturbed by a few things.  First, it appears that each routing
or network device will have a different set of events or perhaps a subset of
possible events that can be generated.  Can I infer from this discussions 
that a DECNIS may, infact report a greater number of events or report them in 
a different manner than say a WANrouter 500?

If so, can someone tell me if the documentation for each router gives specifics
as to just which events can be generated and under what circumstances?

It seems that if DECmcc or for that matter, any network management tool is
to be deployed successfully, the operator must understand which events can
be captured and generated and by which devices.  They must then understand
which events are significant and which can be ignored.  They must, based on
the previous criteria, be able to setup their management station to report,
alarm, display or what ever action deemed important, so as to be useful.

I am now able to capture an event from the router, (currently configured
to run routing vector for both level I and level II routing) when ever an
end node on the same Ethernet becomes unreachable.

The events generated are for NODE * ROUTING CIRCUIT CSMACD-0.  The events
generated are REACHABILITY CHANGE.  The most granular level of CHANGE that
can be obtained or at least set is REACHABILITY.  Not that the circuit is
UP or DOWN, which is reported, but not setable.  This is perhaps an MCC
issue, but to go one step further, in order to identify which end node has
become unreachable, I must be able to identify that node by the Phase IV
DECnet address (i.e. AA-00-04....).  There doesn't appear to be a management
compoment that will correlate either the address or less significant, the
OSI port number/name with that which is easily identifiable to an network
manager, that of the node name.

Again, this is more than likely a management station implementation issue
or is it?  Can you tell me if any of this could be a function of the routing
or network device, to correlate end node addresses or port names with
node names?

Have anyone had much of an opportunity to use DECmcc to monitor our Phase V
routing products and if so, do you have any opinions as to where we fall
short of the mark with regard to making product which can easily report
significant information?

Any comments greatly appreciated.

Thanks,
Al

> However, I am disturbed by a few things.  First, it appears that each routing
> or network device will have a different set of events or perhaps a subset of
> possible events that can be generated.  Can I infer from this discussions 
> that a DECNIS may, infact report a greater number of events or report them in 
> a different manner than say a WANrouter 500?

There will  certainly be some differences between products.  The whole point
of the architecture is to standardise behaviour across implementations.  The
major  differences  will be in terms of different sets of features supported
(e.g.  DECNIS will not log DDCMP events as it doesn't implement DDCMP).  But
there  will  also be some differences caused by software versions (e.g.  the
ROuting  management  architecture  is  changing  significantly to fit in new
routing protocols).  Changes won't be gratuitous but will occur.

> If so, can someone tell me if the documentation for each router gives specifics
> as to just which events can be generated and under what circumstances?

Yes.  There is an event messages manual.

> It seems that if DECmcc or for that matter, any network management tool is
> to be deployed successfully, the operator must understand which events can
> be captured and generated and by which devices.  They must then understand
> which events are significant and which can be ignored.  They must, based on
> the previous criteria, be able to setup their management station to report,
> alarm, display or what ever action deemed important, so as to be useful.

What is  significant  to  one  manager  is useless noise to another.  I very
strongly  believe  that  there is only one way for the manager to set things
up:  start  off  with  *everything*  being treated as significant and remove
those events which are not significant.  

You can't  start  the  other  way  round  because there are large numbers of
events  that  will probably never be seen on your network and may or may not
be  significant.   There  is  no  point  doing  the  work  to understand the
significance of the event unless it is actually reported.

>  This is perhaps an MCC
> issue, but to go one step further, in order to identify which end node has
> become unreachable, I must be able to identify that node by the Phase IV
> DECnet address (i.e. AA-00-04....).  There doesn't appear to be a management
> compoment that will correlate either the address or less significant, the
> OSI port number/name with that which is easily identifiable to an network
> manager, that of the node name.

It is  an  MCC  issue.  The NETMAN architecture specifically deals with this
issue:  it requires that an attempt is made to back-translate addresses into
node names whenever they are displayed.

> Have anyone had much of an opportunity to use DECmcc to monitor our Phase V
> routing products and if so, do you have any opinions as to where we fall
> short of the mark with regard to making product which can easily report
> significant information?

I am  also  interested  in the comments of people using DECmcc to manage our
routing products.

Graham

    While Graham has a good point about starting with all logging turned on
    and then back off, his comments miss the point that is the loudest cry from
    network managers today.  They are overburdoned with management
    information.  With SNMP now providing management from everything from
    routers to power supplies, novice managers are lost.  Which attributes
    are important, which events/traps are noise and which aren't.  What is
    normal, what is low/high?  A change in the thinking process needs to 
    occur.  Those who engineer products with managable attributes
    need to consider which are "front panel" and which ones belong "under
    the covers".  We now have a management system which can look at any
    attribute and alarm on it's behaviour, and supports methods to be
    invoked when an alarm or event/trap is received.  Customers are begging
    for the final engineering work to be done - to build recommended alarms
    and routines to manage devices under "normal" conditions.  Normal is
    not always easy to determine - but it's not rocket science either.  If
    something smart is made the default - those that don't know the
    technology that well will use the defaults, rather than be totally
    boggled by the details.  Those products which get to the point that
    the auto industry has with dashboard "idiot lights" will be noticed.
    
    bill
    
    This is a competitive issue - in that network managers are clearly
    crying out this need - little has been done by anybody - so the
    opportunity is still there - however Cabletron just announced some
    features that approach the problem, and others are bound to follow.

    Graham,
    
    Thanks for the good comments.  I suppose I would have to agree that
    turning on all possible events for a new device makes sense to
    determine just which events are generated over time.  I suspect
    all of us has a good bit of learning when it comes to OSI devices
    and problem solving on OSI networks.
    
    Any comments from the MCC folks as to the determination and reporting
    of node names from DECnet or other types of addresses?
    
    Al
    

    As I understand your test environment, you are using the MCC
    local MIR instead of DNS.  In real life, a person managing
    a phaseV node with MCC should not only be using DNS, but also
    the same namespace as the node is using.  I suspect the hex
    dump of the address is because you aren't using DNS so MCC is
    presenting the info the best it can.

RE:.14......Good information...it is important that everyone understand what
can't be done if DNS is not used.

I suspect many customers today are opting not to use DNS due to its complexity
and difficult management interface.  Particularly those customers that have
the small to medium size shops with no other need for DNS.  I understand that
eventually everyone will need somes form of naming service, but to introduce
DNS just to get some "nice features" of MCC is a bit difficult to accept.



RE:.Bill Gassmans comments.  Thanks for expressing what I've asked for in
perhaps a round about way in note 3570.  Also note...no replys.

I suspect what Graham had in mind was that any network device should not be
prevented from passing any sort of event possible.  The concept of notification
noise would be extemely prevelant if all possible events were allowed to enter
any management station. 

Also the idea of turning on all possible events with a single line completely
overrides the ability of DECmcc to assign priorities and assignments to
individual types of events.  

We and the user community still need some guidance around the mulititude of
events that one would see and one need pay attention to.

Al

    I managed to setup the event logging from DEC X.25 Gateway.

However, I seem to have some problems.

When I issued the command and at the same time enabled the 
"x25 proto dte loop"  elsewhere, I received the "DTE Up" event.
This is OK, like it should.

MCC> getevent node fno:.fno.avex25 x25 proto dte loop any event

Node fno:.fno.avex25 X25 Protocol DTE loop
AT 1992-09-01-15:46:31.041 Any Event

Successfully received events:
Event: DTE Up
                                                   
Unfortunatelly it seems to behave differently when I expect to receive
"DTE Down" event. Somehow the name of the event is missed.


MCC>  getevent node fno:.fno.avex25 x25 proto dte loop any event

Node fno:.fno.avex25 X25 Protocol DTE loop
AT 1992-09-01-15:46:03.963 Any Event

Successfully received events:
                                                        
MCC>
    

Please do the following and post the result.  It will show me what's
being returned to the presentation module from the sink.  Notice I'm
specifying not any event, but the specific event that's giving you problems.
After you give this command, then toggle the circuit to generate the
DTE down event.

$ define mcc_fcl_pm_log 8
$ mana/ent
MCC>  getevent node fno:.fno.avex25 x25 proto dte loop dte down

    I'm running ULTRIX version 1.2.
    
Script started on Wed Sep  2 08:27:33 1992
# setenv MCC_FCL_PM_LOG 8
# manage
DECmcc (V1.2.0)

MCC> getevent node fno:.fno.avex25 x25 proto dte loop dte down


*****************************************************
*     FCL PM Arguments before call_function:        *
*****************************************************

VERB code:      65 
PARTITION code: 15 
AES dump of ENTITY IN:

Depth=0  Class = 1 Instance = fno:.fno.avex25 Id = 1 Dt = 5 
Depth=1  Class = 5 Instance =  No curlen  Id = 0 Dt = 0 
Depth=2  Class = 0 Instance = 
loop  Id = 0 Dt = 4 


ILV dump of IN_P:

[  0 ] ( 
    [  1 ] ( 
        [  1 ]         05 
        )
    )
ILV dump of IN_Q: in_q is NULL 
TIME SPEC is: 0, NOW 

**********************************************
FCL PM Arguments on return from call_function: 

CVR returned:
%MCC-S-RESPONSE, success with response reply

ILV dump of OUT_P:

[  1 ] ( 
    [  1 ] ( 
        [  5 ] ( 
            [  8 ]             01 
            [  9 ]             00 
            )
        )
    )
AES dump of ENTITY OUT:

Depth=0  Class = 1 Instance = fno:.fno.avex25 Id = 1 Dt = 5 
Depth=1  Class = 5 Instance =  No curlen  Id = 0 Dt = 0 
Depth=2  Class = 0 Instance = 
loop  Id = 0 Dt = 4 



Node fno:.fno.avex25 X25 Protocol DTE loop 
AT 1992-09-02-08:28:46.012 CONFIGURATION EVENTS

Successfully received events: 

    
MCC>
    script done on Wed Sep  2 08:29:19 1992

    ahhh.  You found a problem with our definition of the arguments
    returned for that event.  The argument codes should be 8 and 9
    but our dictionary definition has them as 0 and 1.  That's why
    nothing is being displayed.  We have someone working on fixing
    the problem.

>     ahhh.  You found a problem with our definition of the arguments
>     returned for that event.  The argument codes should be 8 and 9
>     but our dictionary definition has them as 0 and 1.  That's why
>     nothing is being displayed.  We have someone working on fixing
>     the problem.

Which problem?  The dictionary or the real problem?

The real  problem  is  that  if  the  event  contains  arguments  you  don't
understand, you must (*must*, MUST) pass on the rest of the information (the
event itself and any arguments you do understand).  That is critical.

Ideally you  use  the  datatype  information  to  try  to format the unknown
arguments  as  well  but  that could reasonably be optional.  What is not an
option,  in  a tool that is designed to help with fault finding, is throwing
the whole event away just because you didn't understand some of it! 

People have  to  be able to rely on event logging: a *lot* of work went into
making  sure  an  event  cannot be lost, anywhere, without notification that
something  was lost.  If they get two events in succession, without an event
indicating  something  was lost between them, then they can rely on the fact
that  nothing was missed between them.  If you break that then event logging
becomes a lot less useful (it is like a diagnostic test which intermittently
fails: seeing it fail tells you absolutely nothing).

Graham

> Which problem?  The dictionary or the real problem?
>
> The real  problem  is  that  if  the  event  contains  arguments  you  don't
> understand, you must (*must*, MUST) pass on the rest of the information (the
> event itself and any arguments you do understand).  That is critical.

We did.  The EVL formatted the event correctly and posted it to the
Event Manager.  By turning the PM log bits we are able to see that this is so.
The event made it all the way through the system up to the PM.
The probem was that the argument codes in MSL for these events were wrong
so when the PM tried to display what it was delivered it couldn't.

> Ideally you  use  the  datatype  information  to  try  to format the unknown
> arguments  as  well  but  that could reasonably be optional.  What is not an
> option,  in  a tool that is designed to help with fault finding, is throwing
> the whole event away just because you didn't understand some of it! 

Sounds good in theory, but consider this.  An event is defined with three
arguments.   Arg 7 = dt_integer, Arg 8 = dt_ltnstring, Arg 9 = dt_uid
The human being which types in the MSL definitions goofs and defines the
event with arg 0,1,2 (this is pretty much what happend in this case).
The presentation module asks the dictionary about arg 7 which is the first
argument in the event.  The call fails because there *isn't* any arg 7.
So, it doesn't have any datatype info to go on to format a display.
If someone from the PM team can confirm my hunch please do.

> People have  to  be able to rely on event logging: a *lot* of work went into
> making  sure  an  event  cannot be lost, anywhere, without notification that
> something  was lost.  If they get two events in succession, without an event
> indicating  something  was lost between them, then they can rely on the fact
> that  nothing was missed between them.  If you break that then event logging
> becomes a lot less useful (it is like a diagnostic test which intermittently
> fails: seeing it fail tells you absolutely nothing).

I couldn't agree more.  That's why when we find these problems we fix them
as soon as possible.

                     <<< Note 3528.21 by TOOK::PURRETTA >>>

>Sounds good in theory, but consider this.  An event is defined with three
>arguments.   Arg 7 = dt_integer, Arg 8 = dt_ltnstring, Arg 9 = dt_uid
>The human being which types in the MSL definitions goofs and defines the
>event with arg 0,1,2 (this is pretty much what happend in this case).
>The presentation module asks the dictionary about arg 7 which is the first
>argument in the event.  The call fails because there *isn't* any arg 7.
>So, it doesn't have any datatype info to go on to format a display.
>If someone from the PM team can confirm my hunch please do.

	That's exactly the same problem as when a specific DECnet 
	implementation returns an attribute that is unknown to the management
	system.

	That's why NCP and now NCL display the attribute code, and since the
	data type is unknown, dump out the value in hex.

	It seems like that (or something equivalent) is what MCC should do 
	as well.  This has been a recurring request since 1.0.

	Hi everybody! :-)

Regards,
Mike

Re: .21.   Thanks  --  its good to know which component is at fault.  When I
said  "you"  I  really meant "DECmcc as a whole" -- not just Phase V AM.  By
the  way,  I  consider  the  Phase  V  AM  to be one of the best implemented
components  of MCC and that the rest of MCC is very good as well -- just not
quite good enough yet!

> Sounds good in theory, but consider this.  An event is defined with three
> arguments.   Arg 7 = dt_integer, Arg 8 = dt_ltnstring, Arg 9 = dt_uid
> The human being which types in the MSL definitions goofs and defines the
> event with arg 0,1,2 (this is pretty much what happend in this case).
> The presentation module asks the dictionary about arg 7 which is the first
> argument in the event.  The call fails because there *isn't* any arg 7.
> So, it doesn't have any datatype info to go on to format a display.
> If someone from the PM team can confirm my hunch please do.

All I  asked  for was that this shouldn't prevent display of the things that
PM  *can*  cope  with  (in this case, the event type was perfectly valid and
should have been displayed).

Like Mike Daniele, I would like to see unrecognised fields displayed in hex.
But  I  know  that  that  is  difficult  in  many designs -- consider that a
wishlist item! What I think is an absolute requirement is that a new version
of  a  managed  object  (hence  with  unknown event arguments or attributes)
shouldn't cause MCC features that could still work to break!

Graham