At layer 1, this is at our physical interface and our physical cabling, where we have configuration characteristics like speed and duplex. Things like your cable length also come into play here. As you may recall, with unshielded twisted pair (UTP) cable, we typically have a maximum run length of 100 meters. Now what happens when you go above these lengths? Well, you end up with some weird issues, perhaps some collisions and maybe some errors on your interface that we can find in our interface statistics and counters when we go into our device.
So let’s first start off here, with collisions. When you take a look at the interface statistics, one of the statistics counters shows number of collisions. What causes these? Most often this is a duplex mismatch. For more information on what exactly duplex is, see the Network Terminology lesson.
Speed and duplex are configurable items. When you have a duplex mismatch and when you’re dealing with cisco devices, CDP also shows a warning that here’s a screenshot of that. This is a level four message for duplex mismatch.
This is a syslog message that’s generated so if you have a syslog collector that is set up to have the information all collected centrally, you might see this syslog message in there. That this would tell you that you have a duplex mismatch and you need to go to one side or the other and either statically configure it or investigate as to why the auto negotiation is not happening correctly.
The other layer 1 property that can cause collisions, is if your cable run is too long. Due to the propagation time, the amount of time it takes for your signal to propagate through the full length of the cable. Let’s say your CAT5 cable run is 300 meters instead of the maximum 100 meters, then you can cause late collisions. Late collisions are the counter that you’ll see incrementing when you have a cable run that’s too long. So if at some point you open up your interface, you go show interface and you see that you’ve got late collisions there, you can bet that probably your issue is that your cable run is too long. The solution here would be to add in a network switch, or migrate to a fiber cable, or something along those lines to resolve that.
An interface error occurs when a frame’s data check doesn’t comply with the standard. So what does this really mean? In the frame’s header we have a piece of data that’s called the CRC, the Cyclic Redundancy Check. This header field is a digest of the data that is located in the payload of the frame, like a hash. When you apply an algorithm to your payload, that should match the CRC that’s there, if it does not then you know either the payload became degraded during transmission or the CRC became degraded during transmission. Also possibly it’s the interface itself is broken in some way and is not actually transmitting the bits that the device wants it to transmit, or possibly the same on the receiver side.
This is where you’ll see input errors, which indicates interface issues on the other end of the cable, it means that the other guy is not transmitting correctly. On the contrary, an output error is where you have problems on your side of the cable, that your interface is not operating correctly, or it could just be overloaded.
First, speed, how is this configured? This is done at the interface configuration level with the speed command. This can be statically set in megabits, to 10, 100, or 1000. If you have 10 gig connection, this will only come up with auto negotiation, there’s no such thing as doing a static 10 gigabit speed. We need to just set it as auto and if it’s configured correctly on both ends then it will come up as a 10 gigabit negotiated speed.
What happens if we have a speed mismatch though? If we have this hard coded to say 100 megabits on one side and then on the other side we hard code a speed of 1000, the interface just won’t come up at all the interface actually just won’t come up at all.