Why on the Same Boards, E5-ENETB, the Associations Did Not Work Towards MSC6 But Worked Towards Other Nodes

Asset ID:	1-71-2149077.1
Update Date:	2016-06-17
Keywords:

Solution Type Technical Instruction Sure

Solution 2149077.1 : Why on the Same Boards, E5-ENETB, the Associations Did Not Work Towards MSC6 But Worked Towards Other Nodes - SGSN, SMSC

Applies to:

Oracle Communications EAGLE (Hardware) - Version EAGLE 3x.x and later
Information in this document applies to any platform.

Goal

1. Why on the same boards E5-ENETB 2116 & 3116 the Associations did not work towards MSC6 but worked towards other nodes - SGSN, SMSC - see config below:

> rept-stat-card:loc=2116

eagle 16-04-13 09:08:22 EET EAGLE5 44.0.4-64.34.24
CARD VERSION TYPE GPL PST SST AST
2116 134-034-024 E5ENETB IPSG IS-NR Active -----
  ALARM STATUS = No Alarms.
   ...
  PEAK TEMPERATURE: = 44C (112F) [16-02-16 01:53]
  SIGNALING LINK STATUS
  SLK PST    LS       CLLI
  A   IS-NR mscp06   mscp06
  B   IS-NR ssmsc101 smsc101sig
  A1 IS-NR mss06    mss6sig
  B1 IS-NR mss01    mss1sig

> rept-stat-card:loc=3116

eagle 16-04-13 09:08:30 EET EAGLE5 44.0.4-64.34.24
CARD VERSION TYPE GPL PST SST AST
3116 134-034-024 E5ENETB IPSG IS-NR Active -----
  ALARM STATUS = No Alarms.
   ...
  SIGNALING LINK STATUS
  SLK PST   LS      CLLI
  A   IS-NR ssgsn04 sgsn04sig
  B   IS-NR mscp06 mscp06
  B1 IS-NR ussdn   ussdnav

2. When the Bugs #19116140 and #19086298 occur, why are all associations not affected? which s/w release solve these Bugs?

Solution

1. You are asking : "Why on the same boards E5-ENETB 2116 & 3116 the Assocs did not work towards MSC6 but worked towards other nodes - SGSN, SMSC "

The answer is :
According to the provided info, there was an operation made on the far end MSC06 which led to the loss of the links.
So why the SGSN and SMC would be impacted by the operation of the MSC06 ?
Also, you indicated this : "the real cause was the optical trunk cable has been damaged in the Thu-3-March morning". Were was located this optical trunk ?

2. Bug 19116140 - [234833] IPSG-M3UA SLK not auto recovering
======== Description ========
It is observed that sometimes IPSG-M3UA link is not getting auto recovered after a link failure.
During such events IPSG-M3UA SLK/ASP recovery attempt by far end is failing as the Eagle continuously outputs UIM 1333 for the link
with "REASON=Refused Management Blocking (Error Code=0x0d)" and "DIAGNOSTIC=ASP-ACTIVE rcvd; SLK OOS-MT-DSBLD"
while link is not actually deactivated on the Eagle.
dact-slk/act-slk is performed on the Eagle that resolves the problem.
║ @
║ @ 6384.1333 CARD 1311,B8 INFO UA RCVD MSG DISCARDED
║ @ IP CONNECTION NAME=i1hb1311b8cust ADPTR=M3UA
║ @ REASON=Refused Management Blocking (Error Code=0x0d)
║ @
║ @ DIAGNOSTIC=ASP-ACTIVE rcvd; SLK OOS-MT-DSBLD
║ @ Report Date:13-10-17 Time:11:27:10

So as you can read in the first sentence of the description, It happens only "SOMETIMES".
It is not predictable, sometimes some links will auto recover after a link failure and sometimes other links will not auto recover.
This bug is fixed in R46.2.0-67.3.0

3. I don't think you are concerned by this bug : Bug 19086298 - [209808] cards reporting ddl noxld, ddl unstbl, status and ddl_mgr sev 1

You simply experienced a DDB inconsistency because of too many status changes about DPC and routes per second.
This is a possible behavior. Moreover it only concerned 3 x SCCP cards.
Eagle recovered on its own after the dynamic status changes reduced.

References

<BUG:19116140> - [234833]IPSG-M3UA SLK NOT AUTO RECOVERING
<BUG:19086298> - [209808]CARDS REPORTING DDL NOXLD, DDL UNSTBL, STATUS AND DDL_MGR SEV 1 DURING L

Attachments

This solution has no attachment