Usually we would connect the same port number on both switches, but that’s not required. If our switches are in different locations and the distance is over 400m or 1300ft or 0.2mi (yeah I love that distance conversion), we will need to use a LW (Long Wave) module, which in general has as blue latch, and to use SM cables (Single-Mode) for long distances. So all in all a good, quick, and easy way to have peace of mind, especially in situations where you might not be working with brand new cable fresh from the ol’ cable tree.If the switches are close to one another, we can use a standard SW (Short Wave) module with a minimum of a OM3 (Blue) cable or Multi-Mode cable.
Link traffic test 11:14:14 RESPONDER - See remote port resultsįinally to pack everything up and head home: Optical loopback 11:14:08 RESPONDER - See remote port results
If you run the stats command from the responder side, you’ll know because…well….Įlectrical loopback 11:14:01 PASSED. I’m ran this from the “master” side switch. Pretty sweet – the test only took 20 seconds, and even gives you latency numbers and cable length estimation (this cable is actually 1m long lest anyone thing that I’ve managed to ISL switches without a cable). Test Start time Result EST(HH:MM:SS) CommentsĮlectrical loopback 14:58:16 PASSED. Now that the tests are finished, we want to see results! Use the following command to get a summary of all port tests on the switch:Īnd use this command to get a lot of nice detailed information about a specific port: Note that the first electrical loopback test failed “due to offline.” This actually happened every time – this is probably due to a quasi-race condition with the port coming online. Sw2:admin> D-Port electrical loopback test started on slot 0 port 23.ĭ-Port test failed on slot 0 port 23 due to offline.ĭ-Port electrical loopback test started on slot 0 port 23.ĭ-Port electrical loopback test completed on slot 0 port 23.ĭ-Port optical loopback test started on slot 0 port 23.ĭ-Port optical loopback test completed on slot 0 port 23.ĭ-Port frame traffic test started on slot 0 port 23.ĭ-Port frame traffic test completed on slot 0 port 23. On my switch, this is what it looked like (switch message output to console in bold/italic, I didn’t type anything after the portenable command): Whatever switch you brought the last port up on will be the “master” of sorts, and the other switch will be the responder. Next, repeat for switch 2 and bring both ports up:Īt this point dport testing begins automatically.
First we bring down and configure the dport on switch 1:Īt this point, from switchshow output the port will look like:Ģ3 23 0a1700 id N16 In_Sync FC D-Port Disabled I ran the following commands (note there are two switches: Sw1 and Sw2…after all these are ISLs). In my case I was adding new switches and wanted to validate 16Gb ISLs, so this was a textbook use case for dport diagnostics. So if you have 8Gb SR (what I consider most common at least in recent times) you appear to be out of luck until you move to 16Gb.įinally, you have to take down the link in order to test it, so it is probably not something you are going to want to run on active production just for kicks…but then that isn’t what it was designed for. Second caveat – two of the tests are only supported with 10Gb, 16Gb, and (sometimes?) 8Gb LR or LW Fibre Channel SFPs. The switch model and FOS version you are running dictate whether you can use the dport testing.
0 kommentar(er)
