- [Instructor] While basic troubleshooting isn't something
that must be done on a daily basis,
it is generally extremely important.
Symptoms of an interface, or cabling issue,
can vary from slow connections, to complete loss of service.
Most often, cabling issues will manifest as complete
failure, which makes things much simpler to troubleshoot.
Often, the easiest thing to do is test and replace
network cables between the two connected devices.
If this repairs the issue, then an engineer
can move on with their day.
If there are other symptoms like slow connections,
I'd generally try something simple, like plugging my laptop
into the connection to see if this resolves the issue.
If the cables have been repaired, and the issue persists
with my laptop in place, I'll examine the switchboard.
I'll hop into the CLI of my Catalyst 3550 Switch here.
My endpoint is plugged into Port 24.
I'll start by issuing a show interface fa0/24 command.
On the effective port.
I'm first looking for any errors or CRCs.
While I do see errors, I don't know if they are old or new.
So I'll take note of how many there are now,
and reissue the command.
Now I can see they are incrementing,
so this is actively an issue.
CRCs and errors are usually indicative of a duplex mismatch,
where one port has itself set to full-duplex,
and the other is down to half-duplex.
Checking the port configuration on the switch,
show run interface fa0/24, I see the speed is set to 100,
and the duplex is set to full.
This means auto-negotiation is off on this port.
So, if the client device isn't also statically set,
then I've found my issue.
Checking the client, I see that it was indeed set to auto,
and it's fallen back to half-duplex.
I've got two options here, either set the switchport
to auto, or statically configure the client.
My preference is always to leave interfaces auto whenever
possible, so I'll adjust the switchport back to auto.
Hit t, interface fa0/24, no dup full, no speed 100.
Now that auto-negotiation is on the port,
I'll clear the counters to make troubleshooting easier.
Clear counters fa0/24, confirm.
Now I'll issue, show interface fa0/24, I see the port
has negotiated to 100 full, and, that the errors and CRCs
have stopped incrementing.
Believe it or not, the duplex mismatch is a designed
behavior, when the auto-negotiation process fails,
the ethernet standard says that a network interface
should fallback to half-duplex, this behavior was originally
meant for interoperability with ethernet hubs.
Hubs are virtually nonexistent in today's networks,
but, their operation is still good to know.
Hubs operate at Layer 1 at the OSI model,
which is the Physical layer.
Hubs really just take an electrical signal,
and repeat them out every other port.
Hubs are inherently half-duplex, meaning they can either
send or receive on a port at one time, but not both.
This means that if a hub is sending information
out of a port to a host at the same time that the host
is sending information to the hub,
there will be a collision, and the information will be lost.
Think of it as a small bridge that can only allow
a single car to pass at a time.
It's for this reason that hubs form
a single-collision domain,
this means that there is a possibility
for a collision on any port.
Network devices use half-duplex logic known
as Carrier Sense Multiple Access with Collision Detection,
to attempt to avoid and detect collisions.
This listens and tries to send when the line isn't busy.
But, collisions will still occur, which slows down
overall network speed.
It's good that modern networks run on switches.
Switches have the ability to transmit or receive
on every port simultaneously.
This means they have full-duplex capabilities
on their ports.
This also means that each port is a collision domain,
collisions are only possible per port
if there is a half-duplex condition, and not across
the entire switch.
Of course, modern switches utilize some additional
intelligence, switches learn Layer 2 MAC addresses,
and keep track on which ports they are available from,
to better forward traffic between devices.
This process is covered in more detail later.
Troubleshooting is one of the most important skills
to master, I always tell my new engineers,
"We earn our salary when everything is broken.
"Not when it's working."