CCENT Lab Notes, Part 1

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.

Lab 1

Switch0 is configured as DHCP server but not working. Can you fix it?

Lab 1

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:

  1. Configure the switch with a VLAN interface on the same VLAN as the PC
  2. 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:

On Switch0:

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#ip default-gateway
Switch(config)#ip dhcp pool accounts

On R1:

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

Lab 2

PC0 can’t ping PC1

Lab 2

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 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.

On R1

R1(config)#router ospf 1
R1(config-router)#no network area 0
R1(config-router)#network area 0

Routes are propagating, and ping is working.

Lab 3

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 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`

Lab 4

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.

On Switch3

Switch(config)#int f0/24
Switch(config-if)#switchport mode trunk`

Now PC1 is pinging its router, and is able to ping PC0.

Lab 5

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.

On Switch1

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.

Lab 6

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.