This is a log of my work on the first 6 of these PackTracer labs for the ICND1 exam.
SPOILERS FOLLOW!!! This is not a guide on how to approach the problems, it’s a review of completed work. This perhaps has educational merit, but please continue only after having completed the labs yourself.
Switch0 is configured as DHCP server but not working. Can you fix it?
Yes, I can. The goal is to get PC-PT to pull a DHCP lease. There were multiple VLANs, isolating Switch0 from PC-PT. There are three possible solutions:
- Configure the switch with a VLAN interface on the same VLAN as the PC
- Configure a DHCP relay on the router, and fix the default gateway for the switch
Both would work, but since we have to assume the VLANs are there for a reason, I went with #2:
Switch>en Switch#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#ip default-gateway 172.16.0.1 Switch(config)#ip dhcp pool accounts Switch(dhcp-config)#dns-server 192.168.0.1 Switch(dhcp-config)#end
R1>en R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int f0/1.10 R1(config-subif)#ip helper-address 172.20.0.2 R1(config-subif)#end
PC0 can’t ping PC1
First, I verify that each PC has correct IP settings, by issuing an
ipconfig. Then, I check if they can ping their routers.
On the routers, I verify interface IPs and routes:
Router#show ip int brief ! Router#show ip route
The route for the 172.20.0.1⁄24 subnet isn’t propagating. A
show run indicates that the network command for that subnet was incorrect, referencing the .2 address instead of the router’s if address.
R1(config)#router ospf 1 R1(config-router)#no network 172.20.0.2 0.0.0.0 area 0 R1(config-router)#network 172.20.0.1 0.0.0.0 area 0
Routes are propagating, and ping is working.
PC0 can’t ping PC1
This is almost exactly the same as the previous lab. I started with the same process. This time, PC1 can’t ping its router IP
172.20.2.1. I verified that PC0 can ping PC1’s router interface, so that isolates the problem a bit. I checked the switches, and they were in their default configuration with good connectivity.
In looking at R3, I noticed that the subnet mask was mistakenly set to /25, putting the PC out of range. It was readily fixed with:
R3(config)#int f0/0 R3(config-if)#ip address 172.20.2.1 255.255.255.0`
Same premise. Immediately, I verify that PC0 can’t ping the outside interface of R2 (though it turns out this was apparently due to pinging before the network came fully online). I also verify that PC1 can’t ping its own router.
Switch2 showed a sad connection light. I logged into Switch2 and Switch3, and found that trunking was enabled on the Switch2 link, but not the Switch3 link.
Switch(config)#int f0/24 Switch(config-if)#switch Switch(config-if)#switchport mode trunk`
Now PC1 is pinging its router, and is able to ping PC0.
This time, I waited for the network to come up. PC1 can ping PC0’s router, PC0 cannot. Fa0/24 on Switch1, which PC0 is connected to, is down/down. A
sh run indicates that the port is shutdown due to a MAC address conflict in port security.
Switch(config)#int f0/24 Switch(config-if)#no switchport port-security mac-address 000A.000B.000C ! and since I assume port-security was intentionally configured Switch(config-if)#switchport port-security mac-address sticky
If this were production, I would have hard-coded the MAC to match the existing config.
What is it with these guys and pinging? The issue is again between PC1 and its default router. Apparently, I should have been reading the logs when I open the device CLIs, because I was greeted with this on Switch2:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/24 (20), with Switch FastEthernet0/24 (10).
Easy. I checked the running-config to verify, and then issued:
Switch(config)#int f0/24 Switch(config-if)#switchport trunk native vlan 10}}
After waiting about 30 seconds, ping began working.