Conference azur::mcc

Chris,

I've seen that error as well (see note 3142). It has been QARed (QAR3170). I 
don't know if it's been fixed yet.

Ian

  ChriS,

  1. Do you know which events are causing MCC to return this error?

  2. Do you get this error only while using Notification Services
     or does it happen if you do a specific Getevent for that event as well.

  This information could help us narrow down where the problem is.
  I work on the DNA5 EVL and haven't seen or heard of this problem
  until now.

  The EVL runs as a separate process so this error message cannot be coming
  from that.  This leads me to believe that the event had been processed
  and posted but something on the output side had a problem unwrapping it.
  It could also mean that there's a problem at the encoding end which is
  somehow getting through, causing an error on the output leg.

  To answer your question about it being fixed in the SSB kit, V1.2 has
  been shipped to SSB already so if you are running the final V1.2 
  as announced in this notes file somewhere, any fixes will have to be
  made in a subsequent version of MCC.

John

John,

>>>  1. Do you know which events are causing MCC to return this error?


The events that causes that error are "NODE xxx ROUTING CIRCUIT xxx ID 
REACHABILITY CHANGE". There are other error on the routing circuit entity that
do not cause this error (eg state change).


>>>  2. Do you get this error only while using Notification Services
>>>     or does it happen if you do a specific Getevent for that event as well.


When using the notification services this error occurs. When using the GETEVENT
command there's no error, but no event text, too. There's only the message,
that the sink has successfully received an event.


>>>  The EVL runs as a separate process so this error message cannot be coming
>>>  from that.  This leads me to believe that the event had been processed
>>>  and posted but something on the output side had a problem unwrapping it.
>>>  It could also mean that there's a problem at the encoding end which is
>>>  somehow getting through, causing an error on the output leg.


If it is helpful for you, I can specify a getevent directive with enabling
the MCC_FCL_PM_LOG. I don't know wether it returns any usefull stuff, it's
just a suggestion.

I am currently using MCC T1.2.7 with the "extended" MCC_DNA5_AM (there's one 
delivered with their baselevel kit, but I have a modified version from Gary
Allison). Since the Sink has its own process and image I'm not sure, if the
AM causes the error. I can copy the image to you if it helps.

Regards

ChriS

Chris,

There was a fix to our MSLs made late in the V1.2 development cycle which
was related to this.  If you aren't using a V1.2 dictionary then this may
be what you're hitting.  We changed the Adjacent Node argument datatype
definition from SetOf ID802 to ID802.  Give the following commands to verify
you're using the latest released dictionary with this fix.

$ manage/tool/dictionary
DAP> use class node subclass routing subclass circuit Event IDREACHABILITYCHANGE
DAP> show Argument ADJACENTNODE Definition VALUE_DATA_TYPE

The value should equal 71.  If you see 52 then you have an old dictionary
definition.


Now, if you _are_ using the latest dictionary and still seeing this problem,
then the FCL dump of out_p would be useful.  No need to send me the extended
AM.  I'm the DNA5 am developer providing Gary with the new features.
It's just exception code mapping anyway.  Completely unrelated to the
problem we're seeing here.

John

John,

It seems to be what you've mentioned. The value of the data-type is 52. So
what's the way to change it. I know how to do it by MSL but not with DAP.
Is there a way to set it with DAP or do I have to reload the (not present)
MSL ??

ChriS

John,

playing around with DAP made it possible for me to change the value of
VALUE_DATA_TYPE to 71. Parse Table update is currently running. I'll
tell you the results as soon as DAP has finished.

ChriS

Commands used:
==============

DAP> use class node subclass routing subclass circuit event idreachabilitychange
DAP> use argument ADJACENTNODE
DAP> set definition code 1 type L count 1 length 4 value 71

It is running, running, running ....

Thanks a lot for the hint.

ChriS

    I suggest you use the dictionary shipped with V1.2.  The change I
    mentioned affects at least 5 other definitions under routing.
    
    Event:
    Adjacency state change
    Initialization Failure
    Rejected Adjacency,
    Corrupted LSP Received
    ID Reachability Change
    Authentication Failure