Routing PBQs and Troubleshooting Route Table Clues
Key Takeaways
Routing PBQs combine route tables, interface status, gateways, VLANs, NAT, and protocol clues into one repair task.
Read a route table by matching prefix length first, then route source code, then next-hop reachability.
A missing route, wrong next hop, down interface, wrong gateway, NAT fault, or ACL can all produce the same user complaint.
ping, traceroute, ARP/neighbor tables, interface status, and the route table together localize the failure.
Always test the return path and decide whether the failure is routing, switching, translation, or filtering.
How Routing PBQs Are Built
Performance-based questions (PBQs) present a partial topology - a few routers, a switch, a route table, maybe a NAT or firewall hint - and ask you to restore reachability. The winning approach is always the same disciplined flow: identify the source host, its default gateway, the routed path, the destination's return path, and any policy controls in between. Change the smallest thing that explains all symptoms.
Reading Route-Table Codes
| Code | Meaning |
|---|---|
| C - connected | Subnet directly attached and interface up |
| L - local | A /32 or /128 for the router's own interface IP |
| S - static | Administrator configured the route |
| O - OSPF | Learned via OSPF |
| D - EIGRP | Learned via EIGRP (D = DUAL) |
| B - BGP | Learned via BGP |
| S* - gateway of last resort | A default route is present |
| (no match) | Packet dropped unless a default route catches it |
Exact code letters vary by vendor, but a PBQ gives enough context. Anchor on four facts per line: source code, destination prefix, next hop, and interface state.
The Troubleshooting Flow
Apply this in order; do not skip ahead:
| Step | Question | Evidence / tool |
|---|---|---|
| 1 | Is the host configured correctly? | IP, mask, default gateway, DNS if name-based |
| 2 | Can the host reach its gateway? | ping gateway, ARP table, VLAN membership |
| 3 | Does the router know the destination? | Route table, longest-prefix match |
| 4 | Is the next hop reachable? | Interface up/up, ARP/neighbor, ping next hop |
| 5 | Does the destination know the return path? | Remote route table and gateway |
| 6 | Is translation involved? | NAT/PAT table, inside vs outside interface roles |
| 7 | Is policy blocking it? | ACL, firewall rule, security group |
User-report decoder
| User report | Best first clue | Likely fix |
|---|---|---|
| One internal subnet cannot reach another | Route table lacks a specific route | Add route or advertise the subnet |
| All offsite networks fail from one VLAN | Wrong host default gateway | Fix the DHCP scope or static gateway |
| Internet fails but private WAN works | Default route or NAT/PAT | Add default route or repair translation |
| Server gets traffic but replies never arrive | Return path missing | Add reverse route or fix the server gateway |
| A dynamic route vanished after maintenance | Adjacency down | Fix interface, protocol settings, or auth |
Longest-Match Practice
Destination: 172.16.8.45
| Route | Next hop |
|---|---|
| 0.0.0.0/0 | ISP |
| 172.16.0.0/16 | WAN-A |
| 172.16.8.0/24 | WAN-B |
| 172.16.8.32/27 | WAN-C |
Work the math: a /27 covers 32 addresses, so 172.16.8.32/27 spans 172.16.8.32-172.16.8.63. The destination .45 falls inside that block, so WAN-C wins - it is the longest matching prefix. If WAN-C's next hop is down and no alternate is installed for that prefix, the router may drop the packet even though broader /24, /16, and default routes still match. This is why "there is a default route, so it must work" is a flawed assumption: a more specific dead route is still preferred over a healthy broader one.
PBQ Repair Examples
| Evidence in the PBQ | Interpretation | Action |
|---|---|---|
| Branch has only a default route; HQ subnet should reach via MPLS | Specific private route missing | Add a static route or fix the advertisement |
| OSPF neighbor absent after a password change | Authentication mismatch | Correct OSPF auth on both ends |
| VLAN 30 gateway responds but no inter-VLAN routing | Missing route or subinterface | Add the routed/subinterface gateway |
| PAT table empty during internet test | NAT not matching traffic | Fix the NAT ACL or inside/outside roles |
| Traceroute stops at the firewall | Filtering or missing route at that hop | Check route table and firewall policy there |
Common Traps and the Exam Tactic
| Trap | Better reasoning |
|---|---|
| Blame DNS when ping by IP already fails | Layer 3 reachability must work before name resolution matters |
| Fix only the source router | Return-path routing breaks replies just as easily |
| Sprinkle broad default routes everywhere | Specific internal routes are safer and easier to reason about |
| Ignore interface status | A perfect route through a down interface forwards nothing |
| Read a traceroute timeout as definitive failure | Some devices silently forward but block ICMP/traceroute responses |
Exam tactic
When a PBQ shows many devices, narrate the flow in your head: source host -> default gateway -> router path -> destination gateway -> destination host -> return. Then change the single smallest setting that accounts for every symptom. If one VLAN works and an adjacent one does not, line up their differences: gateway address, VLAN tag, route entry, and ACL. The differing field is almost always the answer. Resist replacing hardware or rewriting whole configs - PBQs reward a precise edit, and the broader, more dramatic option is usually the distractor.
Finally, sanity-check that your fix does not blackhole other traffic, especially when you add or change a default route.
A server receives packets from a branch subnet, but the branch never receives replies. Which issue should you check first?
The return path (reverse route or default gateway) on the server side
The monitor brightness on the branch workstations
The keyboard layout on the server
The print queue on the branch print server
A route table contains 192.168.0.0/16 and 192.168.10.0/24. Which entry best matches a packet destined for 192.168.10.75?
0.0.0.0/0
192.168.0.0/16
192.168.10.0/24
Neither entry matches
Which two conditions can make a routing problem look like a total connectivity outage to the user?
Select all that apply
A missing default route
An ACL blocking the routed traffic
A correctly installed return path
An accurate route advertisement from the neighbor
Sections you finish are checked off in the contents.