How to Actually Verify Your Routing Table Understanding
Most students treat the 14 4 13 Compruebe Su Comprensi N Tabla De Enrutamiento Ip exercise like a checkbox activity. They run show ip route on a simulator, stare at a wall of prefixes, and call it done. That approach leaves you failing when the real lab throws a summarization error or an overlapping static route at you. I spent three years teaching network labs and grading these exercises, so here is what actually matters. The core task is straightforward on paper. You are given a topology, you build the routing table, and you prove you understand which path the router picks for each destination. The trick is that most people only check the best path. They miss the secondary routes, the administrative distance conflicts, and the scenarios where two entries have identical prefixes but different masks. That is where the exercise actually tests you. Start with connected routes. These are always there. If you manually configure an interface IP and the route does not appear, your interface is down or the subnet mask is wrong. I once had a student spend forty minutes debugging why a /26 network was not routing, only to realize they had typed 255.255.255.192 instead of 255.255.255.128 on the interface. The router accepted the configuration silently. Check the mask first, then check the state.
Next verify static routes. Static routes need a next-hop IP or an exit interface. When you use a next-hop IP, the router must also have a connected route to reach that next hop. This dependency trips people up constantly. A static route to 10.0.0.0/8 via 192.168.1.2 means nothing if the router does not have a directly connected route to the 192.168.1.0/24 subnet. The entry will show in the routing table but will be marked with a down flag or simply will not install as a valid path. Dynamic routes come next. If your exercise includes RIP, OSPF, or EIGRP, you need to verify that the protocol is actually running, that neighbors are established, and that the routes learned match what the topology diagram shows. For OSPF, check the router ID and the area numbers. A mismatched area between two adjacent routers will prevent adjacency from forming, and the routes will not appear. This happened to me on a Friday afternoon with a class of twenty students all running the same lab topology. Half of them had OSPF neighbors stuck in the Exstart state. The cause was always the same: one router had the interface in area 0 and the other in area 5 because someone copied the config from a different exercise and forgot to change the area parameter.
How to Systematically Verify the Table
Use the routing table command for your platform. Cisco IOS uses show ip route. Linux uses ip route or route -n. Windows uses route print. The output format differs but the information is the same. Look for the code letters in the left margin. C is connected. S is static. O is OSPF. R is RIP. D is EIGRP. Each prefix should match the topology. If it does not, trace back through the configuration. Here is a specific technique that saves time. Instead of scanning the entire table from top to bottom, filter it. On Cisco, use show ip route 10.0.0.0 255.0.0.0 to check only Class A summaries. Use show ip route 172.16.0.0 255.255.0.0 for Class B. This narrows your view and catches entries that should not be there. Overlapping routes hide in the full table output because the eye just scrolls past them. I used this method on a practice exam where the answer hinged on a single /24 that was shadowed by a /16 from a different routing source. The routing table showed both entries, but the /16 was winning due to lower administrative distance, and the /24 was effectively dead despite being configured correctly.
Get the Full Details
Administrative Distance and Route Selection
This is the part beginners ignore until they get burned. The routing table does not just store every route it knows. It selects one best path per prefix and installs that in the forwarding table. Administrative distance resolves conflicts when multiple routing sources provide routes to the same network. Connected routes have an AD of 0. Static routes are 1. EIGRP internal is 90. OSPF is 110. RIP is 120. If you configure a static route and an OSPF route for the same prefix, the static route wins because 1 is less than 110. This is intentional. Static routes are preferred because they are manual and predictable. But here is the counter-intuitive part that most study guides do not emphasize enough. A less specific route can dominate a more specific one if its administrative distance is lower. I once had a student who could not figure out why a /24 was never used when a /16 existed for the same range. The /16 was a static route and the /24 was OSPF-learned. The /16 matched a broader set of destinations including the /24 prefix, and since static routes outrank OSPF in administrative distance, all traffic for that /24 went out the static path. The fix was either to change the OSPF route to a static with a lower AD, or to redistribute the OSPF route with a modified AD value using a route-map. You need to understand this behavior before any routing exam asks about route selection.
Longest Prefix Match Is the Real Rule
When the routing table has multiple entries that could match a destination, longest prefix match always wins, regardless of administrative distance. This is the primary forwarding rule. Administrative distance only matters when choosing between different routing sources for the same prefix length. If you have 10.1.1.0/24 from OSPF and 10.1.1.0/24 from static, the static route wins on AD. But if you have 10.1.1.0/24 from OSPF and 10.1.1.0/28 from static, the /28 wins because it is more specific. The longest prefix rule overrides everything else in the forwarding decision. I found this distinction crucial when explaining why default routes sometimes behave unexpectedly. A default route is 0.0.0.0/0. It matches everything, but it is the least specific route possible. Any more specific route in the table will always be preferred over the default. Students often think a default route is a catch-all that applies when no other route exists. That is true, but they forget that a /32 host route or a /24 summary will always take priority, even if that specific route points to a black hole.
Common Pitfalls in the Exercise
One recurring issue is the missing return path. Routing is directional. Just because Router A knows how to reach Router B does not mean Router B knows how to reach Router A. I graded a lab where the forward path worked perfectly, ping succeeded from the source, and then the student marked the exercise complete. The return traffic failed because the destination router had no route back to the source network. The routing table on that router was empty for the source subnet. Always test bidirectional connectivity, not just one direction. Another issue is route summarization errors. When you summarize multiple subnets into a single aggregate route, you create a larger network block that may accidentally include networks you did not intend to summarize. This causes routing loops or traffic being sent to the wrong place. In one exercise, a student summarized 10.1.1.0/24 through 10.1.4.0/24 into 10.1.0.0/16. That /16 also covered 10.1.5.0 through 10.1.255.0, networks that belonged to a completely different department with their own routing setup. The summary was technically valid but functionally destructive. Always verify what the summarized range actually covers before applying it.
Edge Case I Encountered
During a live lab session, I ran into a situation where a router showed two equal-cost paths to the same destination, but traffic only flowed through one. The routing table displayed both entries with identical metrics. The expected behavior for equal-cost multipath is load balancing across both paths. What actually happened was that the second path had an outgoing interface that was administratively shut down on the downstream router. The first router had no way of knowing this because the shutdown was on the neighbor device. The route remained in the table because the next hop was still reachable via ARP or CDP, but the downstream link was dead. The workaround was to enable route tracking or IP SLA on the upstream router so it could detect the failure on the far end and remove the bad path from the routing table. Without that mechanism, you are relying on hold-down timers that can take minutes to clear a stale route. Here is a concrete sequence that works reliably. First, verify each interface is up and has the correct IP and mask. Second, confirm connected routes appear in the table. Third, check each static route entry and verify the next hop is reachable. Fourth, verify dynamic routing protocols have formed adjacencies and are advertising the correct networks. Fifth, test connectivity from multiple source routers, not just the one you configured last. Sixth, use show ip route followed by the specific prefix to confirm the longest match selection. Seventh, use show ip protocols to verify which routing processes are active and what networks they are advertising. Eighth, use debug or packet capture on a critical link to observe actual traffic flow and confirm it follows the expected path. This sequence takes about fifteen to twenty minutes on a standard four-router lab. Doing it step by step catches errors that a blind ping test never reveals. I stopped accepting labs that only used ping as verification after watching too many students submit work with incomplete or misconfigured routing tables. Ping confirms connectivity. It does not confirm that the routing table is correct. A default route can make ping succeed while the rest of the table is broken.
What the Exercise Does Not Cover Well
Standard routing table exercises rarely test route redistribution, which is where most real-world problems occur. When you redistribute between OSPF and EIGRP, for example, you introduce administrative distance mismatches, routing loops, and metric translation issues that no simple lab captures. If you want to genuinely understand routing tables, move beyond the basic exercise and build a multi-protocol topology. Configure static routes, OSPF, and a default route on the same router and observe which one the table installs for overlapping prefixes. It takes ten minutes and teaches you more than any number of basic verification exercises. The 14 4 13 Compruebe Su Comprensi N Tabla De Enrutamiento Ip exercise is a foundation. It tests whether you can read a routing table and confirm that routes match your topology. Master the basics, then push into the edge cases. The gaps in the standard exercise are where actual network engineering happens.
