A few years ago, I was in a project where I was reviewing many Cisco Catalyst Switches and solving connectivity problems in LAN networks in a company that has several branch offices in the provinces of my country, Peru.
It is well known by many network administrators that when we have a connectivity problem on a PC, phone, or other end device connected to a port of a LAN switch, the most common test is through the ping and traceroute commands. Complementary actions include verifications of the ARP table and the MAC address table.
As we can see, the most common test in a connectivity problem begins with layer 3 (ping), then we check if there was a record of the MAC address of the end device in the switchport, which corresponds to layer 2 (mac address table). In case we do not obtain a favorable result in both tests, we could assume that there is a physical disconnection in the network. However, what I want to expose in this blog is a case where I did not get any result in the ping test, no address record MAC in the switchport, but interestingly, the state of the switchport where a PC was connected (with a very important application where users connected remotely) was in the up/up state. This happened at a remote branch regarding my work location, in another province.
This was something that caught my attention, since although the problem is clearly in layer 1, a measurement of the wiring would have had to be done with a network cable tester. However, that instrument was not available at that branch. Even the only network assistant in the branch was not present at that time; therefore, there were only administrative personnel who had no knowledge in networking. The solution at that moment of urgency was to make a diagnosis of the wiring remotely and have a report that supports that diagnosis.
It is true that we have several network cable testers from different vendors (a Fluke network cable tester was available in the central office of the company). However, although Cisco does not manufacture these products, it has always taken into account various methods of testing connectivity on a LAN switch. With this in mind, I started researching it and found that Cisco provides us with a virtual electronic instrument (tester) called: TDR (time-domain reflectometer), which I will describe below.
Time-domain reflectometer (TDR) is a virtual electronic instrument used to test cables, providing a very useful output and thus have information that allows us to support through a report on the failures found in copper cables such as twisted pair (UTP), where I go to focus on this opportunity.
Considerations about TDR:
* Cisco Switches support it from IOS version 12.2 or later. TDR is compatible with IOS version 15.0. Previous versions to IOS 12.2 do not support TDR.
* If we are running IOS version 12.2, the test with TDR could occur sudden interruptions. In other words, the interface will go down and go up. If we test on a switch port that connects to a PC that is functioning properly, the device will lose network connectivity because of the test on that switchport.
* If the device supports PoE, the test will cause the device to lose power. A typical example is the connection of an IP phone and a PC connected to the same switchport, where both the phone and the PC will lose network connectivity.
* Particularly when running older versions of IOS, the test can take five seconds aproximately.
* TDR works in 10/100 / 1000BaseTX (Ethernet). Fiber optic ports cannot be measured by this tester (in Fiber, we can use a useful command such as: "show interface transceiver [detail]" which is supported by high-end switches).
Running the testing with TDR:
The diagnosis is made by switchport, where the corresponding measurement is made first with the following command:
Switch# test cable-diagnostics tdr interface interface-type interface-number
After a reasonable time of a few seconds, we execute the following “show” command where it will show us the result of the measurement made.
Switch# show cable-diagnostics tdr interface interface-type interface-number
As an example, we have a test on the WS-C2960-24LT-L Switch that has FastEthernet and GigabitEthernet ports. Bear in mind that when we use the test on a FastEthernet port, TDR will only test the first two pairs, pairs A and B, since in a FastEthernet connection we only use two pairs on the UTP cable, therefore, pairs C and D will not be tested, and we will get a “Not Supported” output. On the other hand, when measuring at GigabitEthernet ports, all pairs will be tested, since in a GigabitEthernet connection we use the four pairs in the UTP cable.
Testing on a FastEthernet Port - Successful result
Testing on a GigaEthernet Port - Successful result
These outputs can be taken as a reference at the time of testing, since any state of the pair that shows a different condition comparing with shown above, will absolutely indicate a state of failure in the UTP cabling.
With all this, returning to the case I had at that time in the branch office, the switch I was analyzing at the time was the WS-C3560X-24P-S model.
Then, when I made the measurement in the switchport where that PC was connected (fully identified thanks to the record I found in the network documentation), I got the following result:
The presence of states in the UTP pairs such as “Open” and “Short/Crosstalk” clearly indicated a failure in the UTP wiring from the switchport to the equipment, where the connection goes through Patch pannels, which is where we use UTP patch cords for the connections and corresponding horizontal wiring. This will be better understood with the following picture:
The "Open" state indicated a break in one of the pairs of cable during the UTP wiring path, and the "Short/Crosstalk" state occurs when the signal of one cable is mixed with the signal of another cable. It can happen when the cables are damaged or you have a worn or broken RJ45 plug. This produces the "short circuit" effect on the signal.
All these situations served so that the maintenance projects of all the wiring in each branch office and also in the communications cabinets could be started after a certain time.
I'll share another output of other wiring tests performed on other switches using TDR:
By way of conclusion, the intention of what I presented is first to share an experience that I had as a supervisor of a telecommunications project where I also had network administrator functions, while I also showed you a useful tool that we can apply in a Cisco switch. Second, I hope to motivate us to continue studying through courses and the books, blogs, or videos online. A lover of network technologies won't be content with what has been presented here but will also study the network infrastructure in Telecomunications that includes the Structured Cabling and Optical Fiber technologies, adding other characteristics that we must consider when carrying out a telecommunications project.