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?
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?
Which two conditions can make a routing problem look like a total connectivity outage to the user?
Select all that apply