Work three client tickets bottom-up: a wrong gateway, a wrong DNS server and a 169.254 address

Steps

1. Place the devices and cable them as the Links table lists, with Copper Straight-Through cables. Configure R1:

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# interface g0/0/0
R1(config-if)# ip address 10.1.40.65 255.255.255.224
R1(config-if)# no shutdown
R1(config-if)# interface g0/0/1
R1(config-if)# ip address 10.1.20.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

2. Set up SRV1. In Desktop > IP Configuration, enter 10.1.20.10, mask 255.255.255.0, gateway 10.1.20.1 and DNS server 10.1.20.10. In Services > DNS, turn DNS Service On, then add a record: Name files.corp.example, Type A Record, Address 10.1.20.10, and click Add. Leave Services > HTTP on, as it is by default: it is the service the users are trying to reach.
3. Configure the PCs as the tickets found them. PC1: static 10.1.40.77, mask 255.255.255.224, gateway 10.1.40.97, DNS 10.1.20.10. PC2: static 10.1.40.78, mask 255.255.255.224, gateway 10.1.40.65, DNS 10.1.20.99. PC3: select DHCP. This network has no DHCP server yet (lesson 7 builds one), so watch what PC3 ends up with.
4. Ticket 1: PC1 can reach the PC next to it but not the file server. On PC1, work up the layers:

C:\> ipconfig /all
C:\> ping 10.1.40.78
C:\> ping 10.1.40.97
C:\> ping 10.1.20.10

PC2 answers; the gateway and the server do not. Work the block: 255.255.255.224 is a /27 with a block of 32, so 10.1.40.77 is in the block 64 to 95 (broadcast 10.1.40.95), and 10.1.40.97 is in the next block. The gateway is in the wrong subnet. Confirm that the real gateway answers with ping 10.1.40.65, then set PC1's gateway to 10.1.40.65 and ping 10.1.20.10 again: it replies. 5. Ticket 2: the intranet will not load on PC2. Work up the layers again:

C:\> ping 10.1.40.65
C:\> ping 10.1.20.10
C:\> ping files.corp.example
C:\> nslookup files.corp.example

The gateway and the server's address both answer, so link, addressing and the path are fine. The name does not resolve, and nslookup times out. Read ipconfig /all: the DNS Servers line says 10.1.20.99, a server that does not exist. Set PC2's DNS server to 10.1.20.10 and repeat the name tests. Then test the service itself: open Desktop > Web Browser and go to http://files.corp.example. The server's default page loads. 6. Ticket 3: PC3 has no network at all. Read its configuration:

C:\> ipconfig

PC3 shows an address beginning 169.254 with mask 255.255.0.0. That is a self-assigned link-local (APIPA) address: PC3 asked for a lease and nobody answered. It is not a private lease and not a DNS fault. Try once more with ipconfig /renew to confirm no server replies. Because this office has no DHCP server yet, set PC3 statically from the Addressing table: 10.1.40.79, 255.255.255.224, gateway 10.1.40.65, DNS 10.1.20.10. 7. Trace the path, then break it. From PC3:

C:\> tracert 10.1.20.10

Hop 1 is R1 (10.1.40.65) and hop 2 is SRV1. Now shut R1's server-side interface:

R1# configure terminal
R1(config)# interface g0/0/1
R1(config-if)# shutdown

Run the trace again from PC3. It stops at hop 1, and a ping to 10.1.20.10 now returns Destination host unreachable from 10.1.40.65: the last router that answers is where you start looking. On R1, show ip interface brief shows G0/0/1 administratively down. Bring it back with no shutdown and end, and run the trace once more. 8. Look at what the clients learned on the way. On PC1:

C:\> arp -a

The table holds the gateway 10.1.40.65 with R1's MAC address, and no entry for 10.1.40.97, because nothing ever answered for it. Write one line per ticket: the layer it failed at, and the command output that proved it.