Routing is the process of deciding where a packet should go next when its destination is not on the local network. Within Routing Protocols and Route Selection, the current CompTIA Network+ N10-009<\/a> objectives expect candidates to distinguish static and dynamic routing, understand BGP, EIGRP, and OSPF, and explain route selection through administrative distance, prefix length, and metrics. Those ideas are more important than memorizing one vendor\u2019s command syntax because they explain why a router chooses one path when several possibilities exist.<\/p>\n Most routing incidents are not caused by a router having no routes at all. They happen when the router has the wrong route, chooses a less appropriate route, cannot return traffic along a valid path, or learns competing information from multiple sources. A good diagnostic approach reads the routing table as a decision record: which prefixes are present, where they came from, what next hop and interface they use, and why one candidate was preferred over another.<\/p>\n Routing behavior is also time-dependent. A table captured after an outage may already reflect reconvergence and hide the route that was active when users lost connectivity. Monitoring routing-neighbor changes, route withdrawals, and interface events preserves that history. During troubleshooting, distinguish the steady-state table you see now from the sequence of control-plane events that produced it.<\/p>\n A route maps a destination prefix to a forwarding action, commonly a next-hop address and outgoing interface. Connected routes come from directly attached subnets, static routes are configured by an administrator, and dynamic routes are learned through a routing protocol. A default route covers destinations for which no more-specific route exists. The routing table is therefore not a list of individual hosts; it is a hierarchy of prefixes that can overlap.<\/p>\n Operationally, the most useful questions are simple: does the table contain a route that covers the destination, is the next hop reachable, and is the selected outgoing interface up? A route can exist and still fail if the next hop cannot be resolved or if an ACL, tunnel, NAT rule, or return path prevents communication. Route presence is necessary evidence, not proof of end-to-end reachability.<\/p>\n When comparing devices, remember that management displays differ. Some tables show the source protocol, age, metric, and administrative value; others hide detail behind a second command. Build the habit of identifying those fields regardless of syntax. The logic of destination prefix, source, preference, next hop, and interface is portable across platforms.<\/p>\n The most specific matching prefix wins. This longest-prefix rule is fundamental because it explains why a \/24 route is chosen over a \/16 route for destinations inside that \/24, even if the broader route came from a protocol with a preferred administrative distance. Prefix length answers which route describes the destination most precisely; protocol preference and metric are used only among candidates for the same destination prefix or according to platform-specific selection stages.<\/p>\n This is why summary and default routes can coexist with more-specific exceptions. An enterprise may send most internet traffic through one default gateway while installing specific partner or private-network prefixes through a VPN. Troubleshooting becomes confusing when administrators compare metric values across routes of different prefix lengths. First determine which prefixes actually match the destination, then evaluate preference among the relevant candidates.<\/p>\n Longer prefixes can also unintentionally attract traffic. A stale \/32 host route, overly specific static entry, or leaked route can override an otherwise correct aggregate. When a small set of destinations behaves differently from the rest of a network, search for more-specific prefixes before changing the broad routing policy.<\/p>\n Longest-prefix match is a forwarding principle, not a statement about which route was learned first. A broad connected or dynamic route does not override a more-specific route simply because it is older or came from a normally preferred protocol. This is why temporary host routes and narrow traffic-engineering prefixes can have outsized effects. Always compare the actual prefix lengths before discussing protocol preference.<\/p>\n Routers can learn the same prefix from different sources\u2014for example, a static route, OSPF, and BGP. Administrative distance is a local preference used by many platforms to decide which source is trusted when multiple protocols offer the same destination. Lower values are generally preferred, but the exact defaults are vendor-specific. Network+ candidates should understand the concept rather than assume one universal numeric table applies everywhere.<\/p>\n Administrative distance is not an end-to-end property and is not advertised as a universal ranking between routers. One router may prefer a static path while another router elsewhere in the network uses a dynamic route for the same prefix. That can be intentional, but it can also produce asymmetric forwarding. When troubleshooting, identify the route source actually installed on each relevant device instead of assuming every router made the same selection.<\/p>\n Floating static routes use a deliberately less-preferred administrative value so they remain dormant while a primary dynamic route exists. They can provide a simple backup, but they require a reachable next hop and an appropriate failure signal. If the primary path is logically present but unusable beyond the next hop, a floating static route may never take over unless tracking or another mechanism removes the primary route.<\/p>\n Routing protocols calculate or attach metrics so multiple paths learned by the same protocol can be compared. OSPF uses cost derived from interface bandwidth reference values, while EIGRP uses a composite metric based primarily on bandwidth and delay in common configurations. BGP has a much richer policy process in which attributes influence path selection. The practical point is that \u201cshorter\u201d can mean different things depending on the protocol.<\/p>\n Metrics should express the intended path preference. If a low-bandwidth backup link is selected over a high-capacity primary path, inspect how the metric is calculated or configured. Do not change metric values randomly until traffic moves; first determine which protocol owns the route and which part of its decision process is actually active.<\/p>\n Equal-cost multipath is possible when multiple routes are considered equally good. This can increase utilization and resilience, but per-flow hashing may make one application appear to use only a single link. Asymmetric paths can also complicate stateful firewalls and troubleshooting. ECMP is a forwarding behavior to understand, not proof that every packet will alternate evenly between paths.<\/p>\n Metrics also affect failure recovery. If a backup path is only slightly less preferred, it may carry traffic quickly after a topology change; if policy makes it effectively unusable, the protocol may have to explore several alternatives before convergence. Stable routing comes from consistent metrics and clear intent, not from continually tuning values in response to individual traffic complaints.<\/p>\n OSPF is a link-state interior gateway protocol. Routers exchange topology information, build a link-state database for an area, and calculate shortest paths to destinations. The comparison of OSPF and BGP<\/a> is useful because it separates an interior protocol designed for routing within an organization from an interdomain protocol designed around policy between autonomous systems.<\/p>\n OSPF design uses areas to control topology scope and reduce the amount of information every router must process. Adjacencies depend on compatible parameters and network reachability. A route can disappear because an adjacency failed, an interface was placed in the wrong area, a prefix was not advertised, or a filter or summarization choice changed the database. Reading neighbor state and the routing table together is more informative than looking at one in isolation.<\/p>\n Because OSPF is topology-aware, path cost changes can reroute traffic without a physical link failing. That is useful for engineering preferred paths but can surprise operators after bandwidth settings or reference values change. Document intentional cost manipulation and verify both forward and return paths after routing changes.<\/p>\n OSPF troubleshooting should also include interface network type, timers, authentication, and maximum transmission unit expectations when neighbors refuse to progress through adjacency states. The exact commands vary, but the method is consistent: compare the parameters that two peers must agree on before changing unrelated route policy.<\/p>\n EIGRP is strongly associated with Cisco environments and combines rapid convergence with a distance-vector style of route advertisement and a feasibility calculation for loop-free alternatives. Its composite metric commonly uses bandwidth and delay. Network+ does not require the depth expected of a vendor-specific professional exam, but candidates should recognize EIGRP as a dynamic interior routing protocol distinct from OSPF and BGP.<\/p>\n Troubleshooting follows the same broad logic: verify neighbor relationships, check that the expected networks participate, confirm metrics, and inspect which routes are installed. If an EIGRP-learned prefix is missing, a static route or another protocol may be preferred, a neighbor may be down, or redistribution may be incomplete.<\/p>\n In mixed environments, avoid treating EIGRP knowledge as a substitute for protocol-neutral reasoning. The underlying questions\u2014how the route is learned, how preference is determined, and whether a valid return path exists\u2014remain the same even when the protocol changes.<\/p>\n BGP exchanges reachability information between autonomous systems and is central to internet routing, large WANs, and many cloud or service-provider connections. The site\u2019s BGP fundamentals<\/a> explains why BGP is policy-driven: path selection can consider attributes such as local preference, AS path, origin, MED, and other implementation details rather than simply selecting the lowest link cost.<\/p>\n That policy power makes BGP troubleshooting different from simple distance calculations. A route can be reachable yet intentionally not advertised, accepted, or preferred because of policy. Prefix filters, route maps, communities, and attributes may be as important as link state. When working at Network+ level, recognize that BGP is designed to exchange and control routes between routing domains, while OSPF and EIGRP are commonly used inside a domain.<\/p>\n Internet failures often expose the difference between control plane and data plane. A BGP session can be established while a route is filtered, or a route can be present while the actual forwarding path is broken. Verify both the learned prefix and packet reachability instead of using session state as the only health indicator.<\/p>\n At enterprise edges, BGP often interacts with default routes, provider advertisements, and local route policy. Advertising a prefix does not guarantee the remote internet will prefer it, and receiving a route does not require the local router to install it. Filters and attributes should be reviewed in both directions. This is why BGP incidents frequently require cooperation between organizations rather than changes on one router.<\/p>\n Route redistribution imports information from one routing domain or protocol into another. It is powerful but easy to misuse because metrics, filtering, summarization, and feedback loops must be controlled. The site\u2019s route redistribution<\/a> is useful background for understanding why a route that exists in OSPF does not automatically appear in EIGRP or BGP.<\/p>\nRead a routing table as a set of prefix decisions<\/h3>\n
Apply longest-prefix match before other preferences<\/h3>\n
Understand what administrative distance is trying to solve<\/h3>\n
Use metrics to choose paths within a routing protocol<\/h3>\n
Use OSPF for structured interior routing<\/h3>\n
Understand EIGRP as an advanced-distance-vector option<\/h3>\n
Use BGP to express interdomain policy<\/h3>\n
Treat redistribution and policy-based routing as exceptions that need documentation<\/h3>\n