Y cable protection 15454 MSTP 9.1

Unanswered Question
Nov 5th, 2009

Dear all,


Would you please comment the following (in brakets are numbers of sections of the document "Cisco ONS 15454 DWDM Reference Manual, Release 9.1", http://www.cisco.com/en/US/partner/docs/optical/15000r9_1/dwdm/reference/guide/454d91_ref.html):


Issues with Y-cable protection (10.18 Y-Cable and Splitter Protection):

- In a MXP_MR_10DME card provisioned with Y-Cable protection, if a failure is detected on the active path, the traffic is switched to the protect card. In the process of performing the switch operation, the actual end-to-end traffic is affected for up to 15-20 seconds.

- There is a traffic hit of upto a couple hundred milliseconds on the MXP_MR_2.5G and MXP_MR_10DME cards in Y-cable configuration when a fiber cut or SFP failure occurs on one of the client ports.


So does the switchover takes "up to 15-20 seconds" or it takes "couple hundred milliseconds"?


Do you have experience with y-cable protection on "OTU2-XP" cards - how much time it takes for switchover?


Thanks in advance,


Mladen

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Tom Randstrom Fri, 11/06/2009 - 06:22

The way I read the statements is the length of the outage will depend on where the outage occurs in the network.


If their is a cable break in the network between the 15454 nodes, then the outage could be 15-20 seconds.


If the failure is between the 15454 card and the client port, then the outage will be a couple of hundred milliseconds.


I do not have experience with the OTU2 cards.

caoxianglei Thu, 11/12/2009 - 12:52

"If their is a cable break in the network between the 15454 nodes, then the outage could be 15-20 seconds. "


Why is the outage so long?


I think for MSPP maybe the MSP or SNCP switchover time is just 50ms. I think when cable break, Y channel device should be detect the Receive Loss, and then switch over in 50ms, why need 15~20s.

I dont understand.

Tom Randstrom Thu, 11/12/2009 - 13:02

Unfortunately, I do not know why.


From my perspective, the switch time should not exceed that of SNCP. Probably a bug they didn't catch in time to correct.

Actions

This Discussion