No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OSN7500 GNE becomes out of management periodically (each 15-30 min) due to huge number of NEs managed through DCC.

Publication Date:  2012-07-25 Views:  40 Downloads:  0
Issue Description
After fuber cutting in the network (see Network.jpg in the attachment) OSN 7500 GNE (M-60 N Kharkov) became out of management in T2000 periodically (each 15-30 min). Some NEs managed through the GNE also become out of management periodically with the same interval (15-30 min).
OSN7500 GNE software version: 5.21.16.13
T2000 version: V200R006C03
Alarm Information
NE_NOT_LOGIN
Handling Process
Immediate activities:
1) Reduce number of NEs managed through the GNE with problem: in T2000 switch part of NEs to an another GNE, so that the current GNE doesn't manage
 more then 75 NEs (64 NEs are better).
Future (planning) activities:
1) Separate a network to DNC subnets (by closing DCC channels) with at least 2 GNEs and not more then 75 NEs. See "Recomendation_to_DCN_planning.rar" 
in the attachment for more details.
Root Cause
After fiber cutting more then 15 NEs were switched to the OSN7500 GNE from an another GNE at the same time. As result huge DCC traffic must be processed
 by the SCC board of the OSN7500 GNE (number of NEs were managed by the GNE more then 150). Moreover many alarms after fiber cutting might be processed 
in the same time by SCC board of the GNE (because many services of fiber cutted line were termineted on GNE). Aslo, because Customer's SDH network was not 
separated to DCN subnets the ECC rouitng table of the GNE contained more then 250 NEs (see "ECC_table.jpg" for details)  These three main factors led to the 
SCC boards of OSN7500 GNE were overloaded and soft reset periodically.
We can query resseting statistic of SCC boards by typing of command: :mon-get-errlog:bid (where "bid" is slot ID of working and protection SCC boards). As result (see file "SCC_reset_log.doc") we can see many soft resseting of SCC boards
 (both working and protection) with small interval (15-30 min). 
Suggestions
Pay serious attention to DCN planning. Separate big network to DCN Subnets with number of NEs not more then 75. See "Recomendation_to_DCN_planning.rar" 
for details. It will prevent problem with NE management in different conditions of the network.

END