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

Fiber misconnection on nodal SDH NE misleads to the notion that the network works properly

Publication Date:  2012-07-25 Views:  62 Downloads:  0
Issue Description
***************
To sense this case much clear, please open file "Fiber_misconnection_leads_to.doc" in the Attachement.
***************
Network segment structure (see "Network_diagram.jpg" in the attachment).
Initial network state:
1) Services between Source NE and Sink NE (SNCP ring 1) are normal. No any alarms belong to the services on NEs. 
2) Services in SNCP ring 2 are normal.
Problem description:
After fiber cutting occurred on the protection path of Ring 1 (see file "Fiber_cutting.JPG"), the services between Source NE and Sink NE were interrupted.
Why working path of SNCP 1 ring did not work?
Software versions of the NEs are mentioned in the attachmed file "Fiber_connection_diagram&software_versions"
Alarm Information
Alarm event: "SNCP switch"
Handling Process
Go on-site "M-89-Alushta" and replace fibers between port "2" and "3",so the real fiber connection matches the fiber connection in T2000.
Root Cause
Problem analysis:
1) May be there was a problem with physical optical links on any hop of working path?
- No
Checking of optical link of working path of SNCP 1 ring showed up that all hops of the link (Source NE � Nodal NE, Nodal NE � M-88 Yalta, M-88 Yalta � 8-83 Livadiya) were normal. Levels of optical signal on all optical interfaces of all NEs (Sorce NE, M-89 Alushta, M-88 Yalta, 8-83 Livadiya) belong to the link were within the normal range. No any alarms were on optical interfaces of SNCP 1 ring working path. 
2) May be there was a problem with service configuration?
- No
Services configuration checking in SNCP ring 1 showed up that the services configured correctly.
3) May be there was a problem with equipment (such as XC board, line board, PDH board) on any NE of working path?
- No
Hop-by-hop testing (with test cross-connects creation and loopback) showed up that the equipment is normal, but traffic on a hop between Nodal NE and M-88 Yalta cannot be transmitted at all. But physical link on this hop was normal!
4) May be there was incorrect connection of fiber interfaces (the real fiber connection diagram on nodal NE is different from fiber connection diagram in T2000)?
-Yes!
Let’s mark the optical interfaces as showed in the file "Interface_mark.JPG" (see attachment)
a) In T2000 set J0 byte "to be send" to specific value (not "Huawei SBS") on interface "1",Check, whether J0_MM minor alarm appeared on interface "4" (connected
 to interface "1" in T2000). In our case, it is appeared, so that the real connection between NE "M-63-Simpheropol" and NE "M-89-Alushta" are match with the connection on management plane (in T2000). 
b) In T2000 set J0 byte "to be send" to specific value (not "Huawei SBS")on interface "2".Check, whether J0_MM minor alarm appeared on interface 
"5" (connected to interface "2" in T2000). In our case, it is appeared, but on interface "6".So we had the difference between real fiber connection and the 
fiber connection in T2000: interface 2 of NE "M-89 Alushta" is really connected to NE "M-99 ARK Sudak",not to NE "M-88 Yalta".
c) Check the misconnection we found in previous item: set J0 byte "to be send" to specific value (not "Huawei SBS")on interface "3".As result, J0_MM 
minor alarm appeared on interface "5" (connected to interface "2" in T2000). So the NE "M-88 Yalta" and NE "M-99 ARK Sudak" are really connected to NE "M-89-Alushta" in contrary (vise-versa). 
Preconditions of problem appearing:
Before the described problem happen, an on-site reconstruction took place on the site "M-89-Alushta".As result optical interfaces "2" and "3" were connected in contrary. 
Suggestions
1) Unfortunately, when SNCP switching occurs in the SNCP ring no any alarm appears in T2000 on NEs belong to the ring, there is only "SNCP switch" warning 
in management consol (see file "SNCP_switching.JPG" in the attachment for details). 
That's why the fiber misconnection is dangerous. Until you manually check warning messages or status of SNCP services on SNCP dual send or selective receive 
NEs of SNCP ring, you cannot decide whether there is a problem in the SNCP ring. Pay high attention to correct fiber connection during on-site operation (such installation, reconstruction)
2) You can check real fiber connection diagram by typing of Navigator coomand ":cm-get-maccon" on a NE were fibers potentially misconnected. This command show which adjacent NE connected to optical interface board of current NE. Thus, you can 
decide whether real fiber connection is correct or not.

END