CCENT Lab 1 3 Troubleshooting Switch Media Issues v1.0.1
CCENT Lab 1 3 Troubleshooting Switch Media Issues v1.0.1
CCENT Lab 1 3 Troubleshooting Switch Media Issues v1.0.1
DAVID
DAVID
BOMBAL
BOMBAL
David Bombal CCNA Lab Lab 1.3
Task 3: Troubleshoot Connectivity between Switch SW1 and the Branch Router
om
Visual Objective: Troubleshooting Switch Media Issues
l.c
ba Troubleshooting Task 2
om
Troubleshooting Task 1
db
vi
da
NOTE: The following table of commands is reference only. Do not try to type them all
in your lab now. Follow the steps after the table.
om
#show interface #sh int status Displays the current
status Switch interface status
l.c
brief interface status
#show interface #sh int f0/2 Displays the current
ba
FastEthernet 0/2 interface statistics
#show running- #sh run Displays the current
om
om
l.c
Task 1: Initial Lab setup ba
In order to successfully complete this lab exercise, open the Packet Tracer file
‘CCENT Lab 1-3 Troubleshooting Switch Media Issues.pkt’
om
network connectivity. She thinks someone has disconnected her from the network.
All the senior network engineers are out at lunch and you are the only one who can
possibly solve the problem right now. You only have access to SW1, but only via a
vi
Try to determine if you can ping from SW1 to Jennifer’s PC IP address (10.1.1.100)
to verify connectivity exists.
SW1> enable
Therefore, you have confirmed that there is indeed a problem in the network for
Jennifer.
Step 2: Using the appropriate show commands discover what the status of
the interface, which connects to Jennifer's PC1
Remember to use the ? If you need help with commands and the TAB key to auto-
complete commands
om
Fa0/1 disabled 1 auto auto 10/100BaseTX
l.c
Fa0/3 connected 1 auto auto 10/100BaseTX
~output ommitted~
SW1> enable
vi
In this case, everything looks fine from the SW1 output. F0/1 is connected, but you
cannot ping Jennifer’s PC1 address of 10.1.1.100. The PC is directly connected on
F0/1.
Step 3: Double-check with Jennifer that her PC address is correct. You ask Jennifer
to verify the PC IP Address by asking her to confirm the IP settings – She confirms
the settings as follows:
IP Address: 10.1.1.100
Subnet Mask: 255.255.255.0
Default-Gateway: 10.1.1.1
Step 4: You decide to test connectivity to other devices on the network to see if it is
just a local problem for Jennifer.
From the SW1 console, you test connectivity to SW2 and PC2:
om
SW1# ping 10.1.1.12
l.c
Sending 5, 100-byte ICMP Echos to 10.1.1.12, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
ba
SW1# ping 10.1.1.101
om
Step 6: Now you have isolated an indirect problem, correct the issue with the
appropriate commands so you can continue to troubleshoot the issue with Jennifer’s
connection to the network.
SW1# conf t
SW1(config-if)# no shut
SW1(config-if)# end
om
Step 7: Repeat the tests from SW1 to see what connectivity has been restored.
seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max =
0/1/5 ms
db
seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max =
0/0/2 ms
Step 8: OK – you can now ping SW2 (10.1.1.12) and PC2 (10.1.1.101), but you still
cannot ping Jennifer’s PC (10.1.1.100). There has to be a local problem between
PC1 and the Port on SW1.
om
reliability 255/255, txload 1/255, rxload 1/255
Step 9: That is strange – the show interface output confirmed that the interface is
l.c
disabled, but the ‘show interface status’ command showed that the interface was
connected in Step 2 above. In this case, it appears to be a failure of Packet Tracer to
ba
report properly with the ‘show interface status’, but this could also be a result of a
‘bug’ in the operating system. Now you have isolated the problem with PC1, correct
the issue with the appropriate commands in order to get Jennifer’s PC connection to
om
SW1# conf t
db
SW1(config-if)# no shut
vi
SW1(config-if)#end
Step 10: Verify connectivity with PC1 by pinging PC1 IP Address (don’t worry too
much if the first ping times out – This is normal operation for Spanning-Tree Protocol
operations. There are default timers that the switch waits for before allowing data to
go through the ports - just repeat the ping again if this happens and you should be
successful after 30 seconds.)
om
Verify connectivity with PC1 by pinging PC1 IP address again – It should now be
successful:
l.c
SW1# ping 10.1.1.100
ba
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.100, timeout is 2
seconds:
!!!!!
om
Step 11: Now you have verified that the network is functioning properly again, save
vi
Step 1: Using the appropriate show commands from the command list section,
identify the status of the FastEthernet 0/2 port, which connects from SW1 to the
om
Branch router
l.c
On SW1 verify the interface status:
Initially, all looks Ok. However, remember the show int status command may not
be completely trustworthy on Packet Tracer!
vi
da
Branch> en
--ommitted--
You observe that the Line status is UP, but the Line protocol is DOWN – There is a
connection problem. That would explain why the log messages had stopped
reaching the logging server – the connection is down for some reason.
Step 3: From the Branch router console session, verify the interface and observe the
output.
om
MTU 1500 bytes, BW 1000000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
l.c
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ba
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is unsupported, input flow-control is
unsupported
om
---output omitted---
db
You confirm that the router’s interface is UP, but the line protocol is DOWN. You also
know that it is policy to have speed and duplex settings manually configured for
vi
networking devices. From the discovered output on the Branch router, you observe
that the setting are manually configured to match SW1 capability as a 10/100
da
Step 4: Go back to the console session with SW1. Verify the interface settings using
the below appropriate commands.
om
The connection on SW1 is seen as DOWN, DOWN.
l.c
SW1# sh run | begin 0/2
interface FastEthernet0/2
ba
description to Branch Router
duplex half
speed 100
!
om
interface FastEthernet0/3
description to SW2
!
--Output omitted--
db
vi
The interface settings are mismatched, and in this case bringing the interface down.
da
Step 5: Correct the identified issue. Observe the log messages on both SW1 and the
Branch router as you change the duplex setting. Do not forget to save your
configuration at the end.
SW1# conf t
SW1(config-if)# end
om
SW1# copy run start
l.c
ba
Did you know?
Problem Report No.1: Jennifer has called you to say that her company user PC’s
has no network connectivity. She thinks someone has disconnected her from the
network. All the senior network engineers are out at lunch and you are the only one
who can possibly solve the problem right now. You only have access to SW1, but
only via a local console connection.
om
Problem Report No.2: Your colleague calls to inform you that they noticed some
duplex mismatch errors coming from SW1 logging output on the monitoring server
and they were unable to prevent the messages. The senior network engineer has left
you to resolve the issue! Your colleague emails you with an example of the output
l.c
received on the logging server that he wishes you to fix. He also informs you that the
messages have not been received in the last 10 minutes, but would still like you to
look it.
ba
‘%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on
FastEthernet0/2 (not full duplex), with Branch FastEthernet0/0 (full
om
duplex)’
Your objective is to restore connectivity so that SW1 can ping all network
devices.
db
vi
Activity Verification
da
You have completed this task when you obtain these results:
1. You identified and corrected the problem between PC1 and SW1
2. You identified and corrected the problem between SW1 and the Branch
Router