standardization using "dark" fibre (LOS, AIS & RDI)

[valerie]

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 GBIC’s.

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

*******************(Yeah right!)

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 Cisco’s interpretation/strategy/development concerning these kind of matters.

What is the interpretation of (successive) FAULT-EVENTS like LOS, RDI and AIS throughout Cisco’s 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?!)

[CKBudrodeen]

Hi Valerie,

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.

Hope this helps.

Regards.

[valerie]

Hi Graig,

Thank you for taking interest in my question and sharing you’re 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 GBIC’s. 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). I’m 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 Cisco’s 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 you’re suggestion, and I know it seems to be my only option, but I’m 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)

Regards,

Valerie