cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
431
Views
0
Helpful
6
Replies
Highlighted

Check fiber RX/TX on ISL without impact?

Hello all!

On request of the network team our datacenter team provides fiber optic crossconnects between switches. Once these ISLs are in place we can execute a change at a later time to have the interfaces configured and enabled for use in production. Despite the agreement to carefully patch RX/TX strands carefully, the cable needs an RX/TX swap nonetheless and nobody present on location at time of change execution.

One way to have the DC team check RX/TX connectivity is to enable the switch interface when connecting the fiber, but it will immediately take part in spanning tree and other network protocol negotiations, which is strictly prohibited at that time.

Is there a way to enable (Nexus) switch interfaces to allow to verify the optical interfaces signals without interference in network connectivity? I'm thinking of routed interfaces without IP, but maybe there's some other way to allow to check for link connectivity only, and not make it part of network configuration yet.

Kind regards,
Marco

Everyone's tags (1)
6 REPLIES 6
Rising star

Its been a while since i have

Its been a while since i have been engaged in optical networking.

An intelligent cross connect system might have the feature you are looking for.

http://www.glimmerglass.com/

Hi vmiller,

Hi vmiller,

Thanks for your suggestion. The solution I'm looking for should be it a bit more pragmatic. Our DC-team creates Xconnects at one moment (office hours) and network team enables production link after hours.

So isn't there a simple and straightforward solution to make sure RX/TX are correctly aligned when taking into production, something like a 'test interface eth 1/1 fiber-signal' without impact on operation? :-)

Kind regards,

Marco

Rising star

you could always look at udld

you could always look at udld.

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html

Second paragraph down. It is not without  a downside.

If a udld condition is found, the port goe into error disable state.

Hi vmiller,

Hi vmiller,

UDLD is a powerful feature, but it doesn't do what I'd like to achieve:

  1. DC team makes a crossconnect during office hours, but not sure if RX/TX are fit
  2. I can check RX/TX only after change approval, after office hours as e.g. spanning-tree, LACP and vPC will start negotiations

If I can only verify RX/TX during office hours - so link up is guaranteed - I don't need anyone on DC during change execution, as I'm performing change remotely.

Hope this explains the situation...

Kind regards,

Marco

Rising star

I get the situation.

I get the situation.

I do not know of a way to validate TX/RX without bringing a port up active.

Did you try the Optical networking forum ?

VIP Collaborator

Not sure of you're

Not sure of you're environment, but why not just create L3 interfaces on either side and assign temporary IPs that are not included in your routing? (ie 1.1.1.1/30 & 1.1.1.2/30).

This way you'll be able to verify connectivity, there should be no routing protocol peering or neighbor establishment, the network is only known between the two devices and L2 trunking would not come into play. You could also ping across the link to verify link integrity.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards