Conference azur::mcc

Al,

Why not write an alarm against the normal state of the station. These values
are returned for the status:

AT 21-DEC-1992 15:31:17 Status

Examination of attributes shows:
                    nmfoperationalState = Active
                                  State = On
                         Protocol State = Running
                       Maintenance Mode = False
                         Remote Version = %X010002
                        Command Address = 1
                                    UID = EB235BC0-C92F-11CB-8380-08002B1EBBD6

When you drop the link do any of the first 3 'state' attributes change??? If
any do write an alarm against the normal state for not-equal to. Example:

expre=(node x hdlc link syn-0-0 logical station * protocol state <> Running)

Sorry I can't confirm the details myself.

just a thought,
brad...

Thanks for the suggestion Brad, but this could really get to be a maintenance
nightmare.  

As you suggest, the only wild card that I believe will be allowed is the
last field (protocol station *).  This means that for every line on every
router, there needs to be a seperate rule.

This might be tolerable if you could wild card the LINK field, but I've tried
this and it results in an evaluation error.

Can any of the MCC OSI developers tell us if any additional work has been done
to make alarming of OSI rules a practical matter or am I simply using
incorrect syntax?

Al

Al,

You are most correct. I had even thought about this last night and concluded
I would not take the logical station approach because of maintenance issues.
My approach will most likely use HDLC LINK * only, maybe you can test for
feasibility ;-).

Here are the reasons:

1. As you pointed out it is a maintenance nightmare because of wildcarding.

2. Logical Station isn't intuitively a LINK. If I'm going to draw a line on
   a map I would want it to be the LINK and not a logical connection. Also if
   you put logical stations on the map you will be forever changing them as
   the network evolves.

Here is a potential answer:

Using NODE x HDLC LINK * gives the wildcarding needed for alarms and also
stability of LINES on the map. The only question is whether NMFOPERATIONSTATE
or STATE changes for this entity for outages (I would think *something* would
change). It's worth a try but I have nothing to try it on. Also note that this
entity has direct events for LINK UP/DOWN. If you try it post the results cuz
it's only a matter of time before I hit it myself.

regards,
brad...

Brad, Al

You cannot write an alarm that just checks for the state of the HDLC link, as
the link could be state on, and the logical link could also be on, but the 
protocol state would not be 'running' - this is the only real test that things
are running okay. State = ON only means that that child entity is enabled, it
doesn't give any indication as to its operational status.

This is demonstrated in the ncl output below...

NCL>disable node xxxx modem conn line  hdlc-0
Disable Node DEC:.xxxx Modem Connect Line hdlc-0
 at 1992-12-22-15:26:32.87000 + 00:00 I 28147497.67107


NCL>show node xxxx hdlc link * all stat
Show Node DEC:.xxxx HDLC Link hdlc-0
 at 1992-12-22-15:26:52.60000 + 00:00 I 28147497.67107

Status
 State = On
 Physical Port = Modem Connect Data Port $0
 Line Type = NonSwitched
 Actual Sequence Modulus = 128
 Response Address = 3
 Maximum PDU Size = 1495
 Negotiated Crc Type = 16 bit
 Window Size = 8
 Interframe Delay = 0
 UID = 605AE4FF-A5CF-CB11-9340-08002B0B0427

NCL>show node xxxx hdlc link hdlc-0 log stat hdlc-0 all stat
Show Node DEC:.xxxx HDLC Link hdlc-0 Logical Station hdlc-0
 at 1992-12-22-15:27:16.74000 + 00:00 I 28147497.67107

Status
 State = On
 Protocol State = Inoperative
 Maintenance Mode = False
 Remote Version = %X010002
 Command Address = 2
 UID = A0A53000-A6CF-CB11-9340-08002B0B0427

As you will see, there is no status on the HDLC link that indicates anything has 
gone down - you need to check the logical station protocol state.


You don't have this problem with PPP, as you only have a PPP link, and you can 
check the LCP state.

I monitor my circuits by the HDLC link UP/DOWN events, and poll the logical
station protocol state every 10 mins (in case I miss an event).



>2. Logical Station isn't intuitively a LINK. If I'm going to draw a line on
>   a map I would want it to be the LINK and not a logical connection. Also if
>   you put logical stations on the map you will be forever changing them as
>   the network evolves.

I don't see this as an issue, as the logical station is directly related to the
link, (they are pt-pt connections anyway). If you were changing your network
you'd have to change the line on your map anyway (whether it was HDLC link, or
the logical station). Which ever one you choose, you can then use targetting to
get the desired effect, when either the HDLC link event, or logical station 
alarm fires.


Regards

Ian Pratt

Reading Engineering

Ian,

Many thanks for sharing the experience and info. The is truly disheartening
if even the nmfOpState doesn't change at the link level (did you also check
this from MCC??). For our environment I can honestly state that we will *not*
implement an alarm rule for every circuit. We did this in V1.1 for change_of
alarms and we barely kept up with the changes on the net with 100 alarms. It
is too labor intensive. I will hack a script together (or borrow Al's) for
polling our circuits when the day comes. You're observation about lines being
logical stations is probably right and it won't matter. In any event whatever
entity is drawn on the map will tell me if the link is up w/mngmt commands. The
real question gets back to Al and his request for wildcarding info. Without
the wildcards we won't use normal alarms so I repost his question from .2.


>                   -< Not enough wild card fields provided >-
>
>Thanks for the suggestion Brad, but this could really get to be a maintenance
>nightmare.  
>
>As you suggest, the only wild card that I believe will be allowed is the
>last field (protocol station *).  This means that for every line on every
>router, there needs to be a seperate rule.
>
>This might be tolerable if you could wild card the LINK field, but I've tried
>this and it results in an evaluation error.
>
>Can any of the MCC OSI developers tell us if any additional work has been done
>to make alarming of OSI rules a practical matter or am I simply using
>incorrect syntax?

>Al


any answers??? thanks,
brad...

Gentlemen,

thanks both for the good input.

We definatly need a better wild card facility, but in the mean time, I've 
taken the approach of creating a rule for each line.

Currently we have a command procedure that poles each line hourly.
This procedure uses a data file with the name of the router and the circuit(s)
to pole.

I simply wrote a command procedure to read this data file and create another
file with MCC CREATE RULE commands such that the rule is named router#-line#
(i.e. RULE LKGDR1-1 to represent router LKGDR1 HDLC LINK SYN-0-1).

I then poll the specific node, specific link, wild card station for <> RUNNING
as Brad suggested.  I also checked and found the same thing that Ian did
regarding the HDLC LINK status....nothing to indicate change of status.

I've put all of these rules in a single domain, as per Brads findings in
note 24 in MCC_TOOLS.  This should keep the polloing overhead down a bit.

I've also created, at the same time, another procedure that enables each of
these rules thirty seconds apart....assuming that the polling takes place 
from the time of enable....please correct me if I'm wrong on this.

As far as maintenance goes, I can simply enable or disable those rules for
which we have made changes in line status or add new rules as new routers
come on the network.  I can see the name changing to LKGDR1-## when we start
to add NIS routers to indicate line and card numbers.

I have indicated a procedure to run when these rules fire, anticipating that
I will need to take additional action to change color on the correct icon
as well as indicate a corresponding circuit identifier change.

I'll also look into Ian's idea of setting up an event specifically for the
line status.

This will hopefully provide valuable real world experience using DECmcc?!

Again thanks,
Al

Brad, Al,

The nmfoperationalState value doesn't change on either the HDLC link, or the
logical station when the link is down...

MCC> show node xxxx hdlc link hdlc-0 all status

Node MCCULT_NS:.xxxx HDLC Link hdlc-0
AT 23-DEC-1992 11:17:29 Status

Examination of attributes shows:
                    nmfoperationalState = Active
                                  State = On
                          Physical Port = Node MCCULT_NS:.xxxx Modem Connect
                                          Data Port $0
                              Line Type = Nonswitched
                Actual Sequence Modulus = 128
                       Response Address = 2
                       Maximum PDU Size = 1495
                    Negotiated CRC Type = 16 bit
                            Window Size = 8
                       Interframe Delay = 0
                                    UID = FFE45A60-CFA5-11CB-9340-08002B0B0427

MCC> show node xxxx hdlc link hdlc-0 log stat hdlc-0 all status

Node MCCULT_NS:.xxxx HDLC Link hdlc-0 Logical Station hdlc-0
AT 23-DEC-1992 11:17:48 Status

Examination of attributes shows:
                    nmfoperationalState = Active
                                  State = On
                         Protocol State = Inoperative
                       Maintenance Mode = False
                         Remote Version = %X010002
                        Command Address = 1
                                    UID = 0030A5A0-CFA6-11CB-9340-08002B0B0427
MCC>

I would have thought that it should have at least changed value on the Logical 
station - time for a QAR?

I would assume that MCC suffers from the same restriction as NCL, which doesn't
allow multiple wildcards either. Presumably when DECnis's start to roll out on 
Easynet we will be using PPP for the datalink (we certainly will on the 
transatlantic circuits because of the window size restrictions on HDLC). As PPP
doesn't have any logical stations to worry about, this lack of multiple * should
not really affect Easynet anyway (can't comment for external customers though).

Cheers

Ian 

Ian,

>I would assume that MCC suffers from the same restriction as NCL, which doesn't
>allow multiple wildcards either. Presumably when DECnis's start to roll out on 
>Easynet we will be using PPP for the datalink (we certainly will on the 
>transatlantic circuits because of the window size restrictions on HDLC). As PPP
>doesn't have any logical stations to worry about, this lack of multiple * should
>not really affect Easynet anyway (can't comment for external customers though).

I'm not sure if PPP was planned for the whole of EASYnet. But not knowing who
is responsible for the wildcards (mcc or router) or when/if they will be 
implemented is my first ammo for pushing PPP. The US is looking at all kinds
of consolidation where the mngmt domains could end up HUGE so life has got to
be as efficient as possible.

best regards,
brad...

I've noticed in T1.3 that the options have been enhanced to allow us to do
the following:

create domain rules rule MKODR1-1 -
  expre = (change_of (node MKODR1 hdlc link SYN-0-1 log stat * -
  prot state, *, *), at every 00:30:00)

This means that every interval the state is checked and if a change occured
then the procedure will fire and the user written command procedure simply
checks for the new state.  If something other than "Running" then either
leave it alone or take additional action, but if "Running", then clear the
alarm (i.e. change the icon color back to CLEAR).

This should simplify things a bit.

Al

    good eye!
    
    The largest enhancement to T1.3 mcc_alarms_fm was the addition of
    more complete/thorough wildcard handling on all rules.  These included
    items for wildcarding on change_of rules,  domain-based wildcarding
    on occurs rules, and I believe that multiple level wildcarding is
    now also supported for some rule types.  If you get the chance you
    might also want to take a look at the new alarms manager interface
    for the maintenance of rule templates and the ability to quickly
    create new rules from these templates.
    
    

    Hi,
    
    I am having problems helping a customer to figure out how to implement
    an occurs alarm rule format for a DECnis box.  She has successfully
    setup the DECnis to sink events back to the DECmcc host node and sees
    the events in opcom.  We can't seem to figure out how to alarm against
    them.  Is there something that needs to be done similar to MCC_DNA4_EVL
    for phase iv event sinking?
    
    Any pointers in the docs or suggestions are welcome.
    
    BTW, the DECmcc host is running DECnet-VAX extensions and is the load
    host for the DECnis.
    
    Walt
    CSC/CS
    Network Support

    It doesn't sound like you have set up the DNA5 event sink and
outbound streams correctly.

There are several notes in here pertaining to MCC and Phase V events.
Also the DECnet/OSI Access Module Use guide (I think chapter 11, the
last page) and the release notes have instructions on setting up the
DNA5 EVL.

First you need to Enable the MCC DNA5 EVL on the machine receiving events.
 e.g.
MCC> enable mcc 0 dna5_am sink

Next you need to create an outbound stream on the DECnis and
set it so that it will sink the events to the MCC_DNA5_EVL on the
receiving machine.

MCC> create node <decnis> event dispatcher outbound stream <stream_name>

Here's an example of setting the sink address field.  Basicly all I did
was to do a show of the receiving node first and used one of the nodes' towers
but replaced the DNA_CMIP-MICE (or number=82) wih name=MCC_EVL_SINK. (in caps).


MCC> set node <decnis> event disp outb stream <stream_name> -
_MCC> sink address = {([DNA_CMIP-MICE, None], -
_MCC>		[DNA_SessionControlV3,(name = MCC_EVL_SINK)], -
_MCC>	[DNA_NSP,None],[DNA_OSInetwork, 49::00-0C:AA-00-04-00-81-30:20])}

Modifications completed successfully
                           Sink Address = {([DNA_CMIP-MICE,
                                             None],
                                            [DNA_SessionControlV3,
                                             (name = MCC_EVL_SINK)],
                                            [DNA_NSP,
                                             None],
                                            [DNA_OSInetwork,
                                             49::00-0C:AA-00-04-00-81-30:20])}
Then enable the stream
MCC> enable node <decnis> event dispatcher outbound stream <stream_name>

Note that if you wanted a VMS or Ultrix phase V node to send events, you
need not bother with setting the sink address towerset, although it'll
work perfectly well.  Instead you could set the SINK NODE and
SINK END USER NAME fields which are a bit more readable when doing a show
of the outbound stream characteristics.  e.g.

MCC> set node <node> event disp outb stream <stream_name> -
_MCC>   sink node DEC:.foo.bar
MCC> set node <node> event disp outb stream <stream_name> -
_MCC>   sink node end user name=MCC_EVL_SINK

This is because these systems can resolve the address from the node fullname
using DNS.


Now that you've done this, events should be received by the MCC system
and your GETEVENT, NOTIFICATION and ALARM rules should work.

John

    Hi John,
    
    Thanks for the reply!
    
    I did find out about setting up the DNA5_AM sink and got that working. 
    We also setup the DECNIS to sink events back to the DECmcc host node
    but I was under the impression that we could sink the events to the
    traditional NET$EVD process and the MCC_EVL_SINK that got created would
    create a mailbox with NET$EVD to read the events (like dna4_evl and
    evl?).  Is that incorrect?
    
    Thanks again,
    
    Walt

>    but I was under the impression that we could sink the events to the
>    traditional NET$EVD process and the MCC_EVL_SINK that got created would
>    create a mailbox with NET$EVD to read the events (like dna4_evl and
>    evl?).  Is that incorrect?

	The DNA5 sink doesn't operate that way.  It operates the way
	I described.  It accepts connections from an outbound stream
	on name=MCC_EVL_SINK.  MCC_EVL_SINK is a registered DECnet object
	for this purpose.  One advantage of this approach over the way
	phase IV works is that the DNA5 sink will operate in any environment
	(Phase IV or Phase V) and be able to field and post events to MCC.

	To get phase V events to MCC you must set up the environment the
	way I described.

The DECNIS  release  notes  also  have  some information on setting up event
logging to MCC (although John's note in .12 is more complete).

By the way, John, does .12 imply that FCL in MCC V1.3 allows towersets to be
entered?  That would be good news!

Graham

    > By the way, John, does .12 imply that FCL in MCC V1.3 allows
    > towersets to be entered?  That would be good news!
    
    Yes, V1.3 added that support (both in the parser and the AM)
    
    Question for you Graham, I noticed that when I look at how DECNIS
    systems inhouse are configured for sending events to the MCC_EVL_SINK
    they set both the Sink Address *and* the Sink End User Name =
    MCC_EVL_SINK
    
    I thought the address was all that was needed.  Is this setting
    redundant?
    
    John

>     > By the way, John, does .12 imply that FCL in MCC V1.3 allows
>     > towersets to be entered?  That would be good news!
>     
>     Yes, V1.3 added that support (both in the parser and the AM)

Thanks very  much for doing that.  That will help a lot in the effort to get
people to use MCC for more of their management of DECNIS.

>     Question for you Graham, I noticed that when I look at how DECNIS
>     systems inhouse are configured for sending events to the MCC_EVL_SINK
>     they set both the Sink Address *and* the Sink End User Name =
>     MCC_EVL_SINK
>     
>     I thought the address was all that was needed.  Is this setting
>     redundant?

Yes.  If the Sink Address attribute is non-null, the Sink End User attribute
is  not  used.   It isprobably just managers not being sure of the rules (or
maybe just copying the setup of one site who got it to work).

Graham

    Thanks Graham.  That's what I suspected.
    
    John