PlantUML DiagramAsymmetric Path
A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
Users at a branch can ping the HQ file server by IP but can't reach it by hostname. Ping to other sites works fine. Nothing's changed in the branch config. You have console access. What's the diagnosis path?
By-name failure with by-IP success is almost always DNS, not routing. But before you blame DNS, verify the routing path is clean — because asymmetric routing and recursion issues can make specific flows fail while others work. This lesson covers the diagnostic workflow.
Route exists and is selected. Now check the CEF entry to confirm the FIB has the forwarding info (adjacency, next-hop MAC).
`show ip cef <prefix>` includes a `/32` or `/0` lookup — you'll see it as the entry that matches. The `nexthop` line shows the adjacency — the router knows which MAC to send the frame to. If the CEF entry is missing or shows `no route`, the problem is in the control plane (RIB) not the forwarding plane.
Asymmetric routing is a subtle killer. The forward path goes through a stateful device (firewall, load balancer, NAT), but the return path bypasses it. The stateful device sees only half the flow, times out the connection, and drops the reply. Users see "connection times out" while pings in one direction work.
A route to 10.5.0.0/16 goes via next-hop 10.10.20.2, which is itself resolved via an IGP-learned route. When 10.10.20.2 is reachable directly, traffic works. When IGP fails to converge quickly after a link flap, traffic drops for up to 30 seconds. What's the underlying problem?
Select the safest next action.
Finish the lesson once you have worked through the material. This awards ★ 35 XP.