Troubleshooting Lab Challenge 1 Explanation

In this article we will explain the tickets in Troubleshooting Lab Challenge 1.

After reading the configuration you can understand about the topology. To troubleshooting effectively you should know how this network works. We summarize it as follows:

+ OSPF is running among R3, R4, SW5 and SW6, all are in Area 0
+ R1 and R2 are two DHCP Servers
+ R1 is only responsible for answering DHCP Request from SERVER (R3)
+ R2 is only responsible for answering DHCP Request from CLIENT (R4)
+ Interfaces E0/0 of SERVER and CLIENT is running DHCP to request IP addresses
+ There is an access-list named “edge_security” on SW5 that prevents devices which source IP of 172.16.0.x from accessing the SERVER.

In practical, both R1 and R2 should support all DHCP Requests to ensure redundancy but we separate their roles so that more problems can be injected.

Some restrictions in this simulator:

+ Traceroute is disabled on all devices
+ The command “ping ” is supported” but the command “ping source” is not supported

Now we will explain each ticket:

Ticket 1

The first thing we should do in every ticket is checking to see if CLIENT and SERVER can get their IP addresses from DHCP Servers or not. Notice that the CLIENT and SERVER are both routers, not computers so we cannot type “ipconfig” to get their IP addresses. We have to use the “show ip interfaces brief” command (or “show ip interface e0/0” command):

From the output, we see SERVER can get IP 172.16.200.100 but CLIENT cannot so the problem must be somewhere on CLIENT – SW6 – R2. Check the configuration of CLIENT with “show running-config” command and pay attention to E0/0 interface:

The “ip address dhcp client-id Ethernet0/0” command is used to acquire an IP address via DHCP. Whenever a DHCP client sends a DHCP discover, it will send its client-identifier or its MAC address. The “client-id Ethernet0/0” part indicates that the CLIENT will send its E0/0 interface MAC address as its client ID (preceded with a media type code: Ethernet = 01, IEEE 802 = 06, ATM = 16, Frame Relay = 15). For example, if the MAC address of E0/0 interface is aabb.cc00.0400 then the client ID would be “01aa.bbcc.0004.00“.

Without this part (only use the “ip address dhcp” command), the CLIENT will send its default client-identifier. It is a very long number, something like this: 0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3330.302d.4574.302f.30.

In general, the “client-id Ethernet0/0” part makes the Cisco router behaves like a workstation by sending its interface MAC address as the client-identifier.

So the configuration on the CLIENT is good. We continue checking SW6, especially interface E0/0 which connects to the CLIENT with the “show running-config” command:

Ahhhhhh, port-security is configured on this interface! And this MAC 0000.0000.0001 seems unpractical. We can double check the port-security status of E0/0 of SW6 with the “show port-security interface e0/0” command:

The (default) “maximum MAC Addresses” allowed is 1 and we have 1 “configured MAC Address” too. Also we see the “Security Violation Count” is 1 which means that a violation has been occurred. We also know that if a violation occurs, this port will be put into “shutdown” state (from “Violation Mode: Shutdown” line). This is also the default setting of port-security. Check the status of E0/0 with the “show interfaces e0/0” command on SW6:

The E0/0 interface has been put into err-disabled state (same as shutdown state). Therefore now we can conclude the problem here is port-security violation of SW6. In the simulator click on the “QA” button (at the right-hand side) and select:

Answer 1) SW6
Answer 2) Port-security
Answer 3) In Configuration mode, using the ‘interface e0/0’, then ‘no switchport port-security’, ‘no switchport port-security mac-address 0000.0000.0001’ followed by ‘shutdown’, ‘no shutdown’ interface configuration commands.

Then click “Done” to check your answers. If the result is “Correct!” then you had a correct answer!

Ticket 2

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see both were assigned correct IP addresses.

Step 2) Try pinging from the CLIENT to SERVER we get “…..”, but of course something is wrong here.

Step 3) Try pinging from the CLIENT to its nearest device SW6 with the “ping 172.16.100.1” command. It’s good.

Step 4) Try pinging from SW6 to SERVER with the “ping 172.16.200.100” command. We get “U.U.U” but remember the access-list on SW5 is blocking the ping because of company security policy (access-list configured on SW5)

Step 5) We can overcome the policy by jumping into SERVER and try pinging SW6 with the “ping 172.16.200.100” command. We get “!!!!!”, so it’s successful. Hmm, the path between SERVER to SW6 is good. So maybe we should double check the CLIENT.

Step 6) Issue the “show ip route” command on CLIENT so see if it has a default route to SW6 or not:

The CLIENT has no default route so it cannot find out how to reach the SERVER (172.16.200.100) -> ping packets are dropped. So why is the default route missing on the CLIENT? This is because the CLIENT does not have a default gateway. The CLIENT is using DHCP so maybe the DHCP Server forgot to assign a default gateway. So we’d better check the DHCP Server R2.
Step 7) Check R2 DHCP Pool with the “show running-config” command:

Wow, it is missing the default-route (default gateway) for the DHCP Client, only a DNS server was assigned! So of course the CLIENT is not assigned a default gateway.

Now we can answer this ticket:

Answer 1) R2
Answer 2) DHCP
Answer 3) Under CLIENT pool, enter the ‘default-router 172.16.100.1’ command.

Ticket 3

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see only SERVER got the IP so the problem is related to CLIENT.

Step 2) Check the DHCP setting on interface E0/0 of CLIENT, we see no problem (the line “ip address dhcp client-id Ethernet0/0” is enough to get DHCP)

Step 3) Check the DHCP configuration on R2 with the “show running-config” command. But nothing is wrong…

Step 4) Check SW6 as it is in the middle of CLIENT and R2. CLIENT cannot get DHCP information maybe a result of SW6 misconfiguration. First, we should check if CLIENT is assigned correct VLAN 100 or not. Issue the “show vlan” command on SW6:

So E0/0 of SW6 (connected to CLIENT) is assigned wrong VLAN 200 instead of 100. We can verify with the “show run” command on SW6. Now we can answer this ticket. Click on the “QA” button and select:

Answer 1) SW6
Answer 2) Access Vlans
Answer 3) In Configuration mode, using the ‘interface e0/0’, then ‘switchport access vlan 100’ command.

Ticket 4

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see only CLIENT got the IP so the problem is related to SERVER

Step 2) Check the DHCP setting on interface E0/0 of SERVER, we see no problem (the line “ip address dhcp client-id Ethernet0/0” is enough to get DHCP) so the problem maybe is on SW5 or R1

Step 3) Check the DHCP Pool on R1. Please notice that with R1 DHCP configuration, only device with MAC address of aabb.cc00.0300 will be assigned an IP address of 172.16.200.100. We can verify the MAC address of E0/0 of SERVER via the “show interface e0/0” on SERVER. It is matched to the configured MAC on R1. So the configuration on R1 is correct.

Step 4) Check the configuration on SW5. First we should check VLAN configuration for E0/0, which is 200 and it is correct. Check the Interface Vlan 200 with the “show run” command:

We should double check the access-list “edge_security”. But this access-list is correct (prevents subnets 172.16.0.0/24 subnet from accessing SERVER (172.16.200.100).

But wait! DHCP Request sent from SERVER is a broadcast packet. When receiving it on interface Vlan 200, SW5 will not forward a broadcast packet (SW5 acts as a router). To allow SW5 to forward DHCP Request, the “ip helper-address” must be configured under interface Vlan 200 of SW5. Now we can answer this ticket:

Answer 1) SW5
Answer 2) DHCP
Answer 3) Under Interface Vlan 200, enter the ‘ip helper-address 172.1.1.1’ command.

Ticket 5

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see only SERVER got the IP so the problem is related to CLIENT.

Step 2) Check the DHCP setting on interface E0/0 of CLIENT, we see no problem (the line “ip address dhcp client-id Ethernet0/0” is enough to get DHCP)

Step 3) Check the DHCP configuration on R2 with the “show running-config” command. If you look carefully you will see the network range for DHCP assignment in the DHCP pool is not correct: “network 172.16.100.0 255.255.255.252“.

You can also use the “show ip dhcp pool” command to see the IP address range of CLIENT pool.

With this network only IP from 172.16.100.1 to 172.16.100.3 can be issued but notice that R2 also has a DHCP “exclude range” from 172.16.100.1 to 172.16.100.10 so no IP can be issued. In conclusion, the answers should be:

Answer 1) R2
Answer 2) DHCP
Answer 3) Under CLIENT pool, change the subnet masks of allocated IPs to 255.255.255.0

Ticket 6

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see only CLIENT got the IP so the problem is related to SERVER

Step 2) Check the DHCP setting on interface E0/0 of SERVER, we see no problem (the line “ip address dhcp client-id Ethernet0/0” is enough to get DHCP) so the problem maybe is on SW5 or R1

Step 3) Check the DHCP Pool on R1. We see R1 DHCP pool can only assign an IP address of 172.16.100.100, not 172.16.200.100 as planned. But R1 will not assign an IP address for the DHCP Request sent from SERVER because the giaddr field (172.16.200.0/24) is not in the same subnet as the DHCP host (172.16.100.100/24). More detail about giaddr field is explained below.

Notice that when SERVER sends a DHCP Request, SW5 (with the “ip helper-address 172.1.1.1” command) acts as a DHCP relay agent and Interface Vlan 200 (172.16.200.1/24) of SW5 will relay it to R1 (172.1.1.1). SW5 also inserts the IP address of the interface containing the ip helper-address command into the gateway IP address (giaddr) field of the DHCP packet (172.16.200.1 in this case). This IP address enables the DHCP server to determine which subnet should receive the packet.

Note: “ip helper-address …” interface command instructs a router to intercept DHCP broadcast messages and forward them as unicasts to the DHCP server hence providing “relay” functionality.

Therefore the answers should be:

Answer 1) R1
Answer 2) DHCP
Answer 3) Under SERVER pool, change the DHCP reservation host to 172.16.200.100/24 and change the default-router to 172.16.200.1

Ticket 7

Step 1) First check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command. We see only CLIENT got the IP so the problem is related to SERVER

Step 2) Check the DHCP setting on interface E0/0 of SERVER, we see the line “ip address dhcp”. Do this configure get the IP address from the DHCP Server. We have to check R1 DHCP configuration with “show run” command

With this configuration, R1 only assigns IP address for the device with MAC address of aabb.cc00.0300 (the prefix 01 is the Ethernet media type code) in the DHCP Request. But with “ip address dhcp” command, SERVER will send its default client-identifier 0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3330.302d.4574.302f.30 (we are sorry but we don’t know how SERVER gets this). This client-identifier is different from the one configured on R1 so no IP address is issued.

Therefore the answers should be:

Answer 1) SERVER
Answer 2) DHCP
Answer 3) In Configuration mode, using the ‘interface e0/0’, then ‘ip address dhcp client-id E0/0’ command.

Ticket 8

Step 1) Same as other tickets, we should check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command first. We see only CLIENT got the IP so the problem is related to SERVER

Step 2) Check the DHCP setting on interface E0/0 of SERVER , we see no problem (the line “ip address dhcp client-id Ethernet0/0” is enough to get DHCP) so the problem maybe is on SW5 or R1

Step 3) Check the DHCP Pool on R1 but find no problem

Step 4) Check the SW5 config but find no problem

Step 5) We knew SW5 relays the DHCP Request to R1 with IP address of 172.1.1.1 so we should ping to this address from SW5 to make sure it is still up. But the ping is not successful so we should check the config of R1 with “show ip int brief” (to see if this IP exists and the interface with that IP is up), “show run”, “show ip ospf interface” or “show ip ospf interface brief” commands (to see if OSPF is enabled on that interface). For example the output of the “show ip ospf interface brief” command on R1 is shown below:

So we can conclude the interface with IP 172.1.1.1 is not running OSPF. Double check the “router ospf 1” part of R1 with “show run” command:

R1 forgot to enable OSPF on 172.1.1.1 so SW5 does not know how to reach this IP.

Therefore the answers should be:

Answer 1) R1
Answer 2) IPv4 OSPF Routing
Answer 3) Under OSPF process 1, enter the ‘network 172.1.1.1 0.0.0.0 area 0’ command.

Ticket 9

Step 1) Same as other tickets, we should check the IP addresses on SERVER and CLIENT with the “show ip interface brief” command first. But we see both got IP addresses so try pinging from CLIENT to SERVER. We get “U.U.U” (“U” abbreviated of “Unreachable”. For your information, the “Unreachable” message in this case means “CLIENT had sent a ping successfully but its gateway could not get to the destination for some reason, so its gateway responded to the CLIENT with “Unreachable” message.

Step 2) We should check if SERVER and CLIENT already has a default gateway or not with the “show ip route” command:

SERVER and CLIENT uses DHCP to get IP & default gateway so we will see a “S*” line like the output above. So the configuration on SERVER and CLIENT are good.

Step 3) Check the routing tables on SW5 and SW6 to make sure they know how to reach 172.16.100.0/24 and 172.16.200.0/24 subnets, respectively. We can see they learned these routes via OSPF -> no problem here.

Step 4) Nothing is wrong with the routing so we had better check if any access-list is blocking on the way. As we knew, there is an access-list on SW5 so we should double check it. We can use “show access-lists” or “show run” command:

Wow, the “edge_security” access-list only contains one “deny” statement. But remember there is always an implicit “deny any” at the end of each access-list so this access-list will drop anything. Scroll up to see where this access-list is applied to:

So it is applied to interface Vlan 200, outbound direction. Maybe the direction to apply an access-list to an interface Vlan is a bit unclear. When applying an access-list to an interface Vlan:

+ “in” direction: for traffic originating from that VLAN to outside
+ “out” direction: for traffic originating from outside towards that VLAN

In this case, with the “deny ip 172.16.0.0 0.0.0.255 host 172.16.200.100” statement, the access-list is applied outbound for traffic from outside towards VLAN 200 to filter packets with source IP of 172.16.0.0/24 and destination of 172.16.200.100.

Of course with the implicit “deny any” statement, all traffic to SERVER will be dropped so the answers should be:

Answer 1) SW5
Answer 2) IPv4 layer 3 security
Answer 3) Under the ‘ip access-list extended edge_security’ configuration add the ‘permit ip any any’ command.