The second trouble ticket that I was able to demonstrate my TSHOOT knowledge was the following:
Trouble Ticket #2 - the customer reported that hosts at SiteC were not getting a DHCP allocation from the server at SiteD.
The customer reported that when they performed a traceroute from the LAN at SiteC to 192.168.10.10 on the LAN at SiteD the trace stopped. The network looked like this:
SiteC --> R1 at SiteC --> 'the core network' at R2 --> R3 at SiteD --> DHCP Server on SiteD LAN
For this one I took a look at our Nagios Monitoring and could see that there were no issues reported on R1, R2, or R3. As such I jumped on to R1 at SiteC and performed a traceroute to 192.168.10.10. The trace was successful! Yet from the LAN at SiteC the trace failed?
Based on this information I formed my hypothesis. I asked the customer whether there could be an access-list/firewall between R3 and the DHCP server that could be blocking traffic from the LAN at SiteC? The customer investigated their equipment and found that an earlier change to an access-list on their equipment at SiteD was now stopping DHCP requests from SiteC. They corrected their configuration and the issue was resolved.
Trouble Ticket #2 - Closed
With this ticket because our network monitoring was reporting no issues with R1, R2, R3, I took the 'Shoot from hip' approach and looked to eliminate all L3 issues in one go. The trace route worked indicating that the server was responding to ping and that all L3 connectivity between SiteC and SiteD was fine. I could have tested the L1/L2 physical connectivity on each router in turn but our monitoring would have pick this up and therefore I was confident the physical connectivity was fine. Once L3 connectivity had been proven on the equipment I have admin access on I could formulate my hypothesis and put it to the customer to test.