standardization using "dark" fibre (LOS, AIS & RDI)
Recently I preformed several test-cases to monitor the behaviour of different platforms connected via Gigabit Ethernet Interfaces. This due to the growing importance of this type of forbandwidthsakepleasehurry-connections within our network (goal of the test was; what is notified if the Tx or the Rx is removed ?!. Do I get some SDH-like LOS and/or RDI norifications?).
The test-setup I used was; a Cisco 7513 (GEIP+, with VIP4-80 arch.) connected to a Catalyst 6509 (WS-X6416-GBIC) and from this Catalyst (from an identical 'but different' line module) to a 12016 GSR (GE-GBIC-SC-B).
So, straightforward, three platforms connected in a serial setup using two dark fibre connections and SX-based GBICs.
The testing started, and so did the nightmare!!!
Removing the Rx connector from the GSR showed a 'correct' syslog notificaton telling that the light was turned off (surprise,surprise, a LOS). Here is a fragment of the SYSL notification;
Jan 22 11:14:46 GSR 35: Jan 22 11:14:45: %GRPGE-6-RX_LOS: Interface GigabitEthernet0/0: Detected RX Loss of Signal
Jan 22 11:14:46 GSR 34: Jan 22 11:14:45: %GRPGE-6-SYNC_LOSS: Interface GigabitEthernet0/0: Loss of Sync
Jan 22 11:14:47 GSR 36: Jan 22 11:14:46: %GRPGE-6-GBIC_TX_FAULT: Interface GigabitEthernet0/0: GBIC TX Fault OK
Jan 22 11:14:47 GSR 37: Jan 22 11:14:47: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down
Jan 22 11:14:48 GSR 41: Jan 22 11:14:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
The remote side (the Catalyst) never had any notion of what the hxxx" just happened, it likely decided to try to spoof the situation with the following message;
Jan 22 11:14:46 Cat6509 2004 Jan 22 11:14:45 MET +01:00 %DTP-5-NONTRUNKPORTON:Port 4/1 has become non-trunk
From this point on it never improved with my test-cases to the standard I had expected to find (so I will not bore people any further)
Only the GSR(-line module?) seems to have some kind of intelligence on this (management-)issue. The other platforms (the Catalyst and the 7513, also directly connected) never understood the nature of the problem and YES, between the blablalabla-SYSL-notifications they also indicated a Node status major and an Interface down message but blablabla I did expect a bit more,..going straight to the problem!!!
Before I continue to test (interconnectivity with) other platforms (like a Cat-3550) I was wondering if someone can provide enlightenment on Ciscos interpretation/strategy/development concerning these kind of matters.
What is the interpretation of (successive) FAULT-EVENTS like LOS, RDI and AIS throughout Ciscos product-family for GBIC based connections?
Did I miss a document that talks about standardization?, or a special command to enable this ? or is dark-fibre really dark and nobody cares?
What are my options if I deploy more and more of these connections within our operational network regarding network-management (to the point/no nonsense notifications!)
.Am I the only one wondering around with questions like this?! (do I need help?!)
Re: standardization using "dark" fibre (LOS, AIS & RDI)
I think the intelligence you are looking for lies in the Network Management software, not in the syslog messages back on the device.
For example, the software monitoring the GSR may (or may not) have the intellgence to see that there is a LOS, and an up/down. It would then correlate these to present an alarm to your NOC that indicates a cable problem.
Some software comes with these features, and other NMS software has the flexibility for you to write your own rules.
The 7513 will not give LOS alarms, because the link from the 7513 to the Catalyst is OK.
The Catalysts can be difficult. If your running the Hybrid IOS, configuring syslog to alarm on LOS may not be in the default config.
Re: standardization using "dark" fibre (LOS, AIS & RDI)
Thank you for taking interest in my question and sharing youre professional view and solution with me on this matter.
The nature of my question was (and still is) based on the overall introduction of Gigabit Ethernet over dark fibre, using either S-, L- or ZX GBICs. A technology which nowdays is integrated in many different platforms (even different vendors) and still rapidly growing, and how to manage this transmission-mechanism from a NOC point-of-view.
This, in the mean time, proven transmission-technology is very promising ($$$) and without a doubt has a solid future. I might not have been that expliciet at first but I did also remove the Rx-connector between the Cat 6509 and the 7513, and they all tell me something different(?????).
My conclusion of the test-cases I preformed is that there is no generic alarm list (e.g according to an ITU-T) to (re)present the same event happening (me removing the Rx-connector) in a chain of different platforms.
So,..what troubles me is that one transmission technology, carrying the traffic from box A to B via C, is interpreted different (based per box?!).
The company I work for started with a SDH-architecture and has build their services upon it, including the method of Network Management and interpreting fault events when occuring.
I know that a transmission technoloy like 'S'DH requires generic detection criteria like the specified standard ITU-T Rec. G.783, ..but why is it that an Asynchronous transmission path not requires the detection of something going wrong (loss of laser-light). Im pleased to say that we, as a company, are growing which is pushing us to use more-and-more Gigabit Ethernet. But how do I sell Ciscos clumsy interpretation (which I am forced to deploy in the network) to the boys at our NOC. (e.g Interpret this notification on box A like this, on box B it will state this notification for the same event. Box C will state blablabla...) Don't think it should work like that.
I appreciate youre suggestion, and I know it seems to be my only option, but Im still convinced that a basic-simple issue like this should be standardized. One transmission technology should be interpreted in the same way on different types of devices, ..and Yes I think Cisco should have some kind of statement on this. I will continue my struggle in making this a better world (call me Don Quichot) because I do believe I have a valid point.
(Hope, from you're professional point of view, you agree with me)
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...