A branch changes its preferred uplink after a maintenance window, and an engineer notices an odd pattern: the same prefix appears healthy in the routing table, but some application traffic still chooses the slower circuit. The explanation may involve the routing protocol’s metric, administrative distance between protocols, or a route-map that changes the next hop for selected flows. These are three different decision layers. An enterprise engineer must know which layer made the observed choice before altering a network-wide route policy.
Cisco 350-401 ENCOR v1.2 calls for comparing EIGRP and OSPF concepts, configuring simple OSPFv2/v3 multiarea environments, configuring directly connected eBGP, and describing policy-based routing. This discussion concentrates on EIGRP-versus-OSPF behavior and PBR boundaries. The existing multiarea OSPF design and enterprise BGP specialists go deeper into their respective technologies. Do not confuse ENCOR’s compare/describe verbs with the broader troubleshooting scope of the 300-410 ENARSI concentration.
Distinguish topology discovery from path selection
Enhanced Interior Gateway Routing Protocol (EIGRP) uses its Diffusing Update Algorithm (DUAL) to maintain loop-free routing decisions based on feasible distances, reported distances, neighbor information and metrics. Open Shortest Path First (OSPF) uses a link-state database within an area and calculates shortest paths using the SPF algorithm. Both can adapt to failures, support equal-cost routing in appropriate cases and carry enterprise reachability, but they reason about the network differently.
A routing design should first describe the topology, the administrative domains and what must happen when links fail. EIGRP’s neighboring and query behavior may make sense in an existing homogeneous deployment, while OSPF’s areas can provide a scalable way to partition link-state flooding. Neither automatically solves poor summarization, inconsistent routing policy or hidden convergence dependencies. A protocol chosen only because one CLI is familiar can become difficult to operate when the network grows.
Understand EIGRP’s feasible successor idea
An EIGRP router tracks the best-known distance to a destination and the distances reported by its neighbors. A feasible successor is a candidate backup path that satisfies DUAL’s feasibility condition: its reported distance is strictly less than the local feasible distance. This is a conservative loop-prevention condition, not a claim that every useful alternate route is already listed as a feasible successor. If no feasible successor is available after a path fails, the route may enter an active computation while neighbors participate in finding a new loop-free path.
Consider a branch with two upstream routers. One neighbor offers a preferred route and the other reports an alternate route. Examine the successor and feasible distance before assuming an immediate failover will be possible. An alternate that fails the feasibility condition may still be usable eventually, but it cannot simply be installed as a safe precomputed backup under that condition. This distinction is important for explaining convergence delays without blaming the physical circuit. The EIGRP troubleshooting specialist treats detailed neighbor and query behavior as its own deeper task.
Read OSPF area and cost decisions correctly
OSPF forms adjacencies with eligible neighbors, exchanges link-state information, and computes routes from the resulting database. Costs guide shortest-path selection inside the protocol, while area boundaries control how topology information is organized and summarized. Area 0 acts as the backbone in a conventional multiarea design. Area Border Routers connect areas, and the distinctions among normal, stub, totally stub and NSSA behavior matter because not every route type is meant to appear everywhere.
When an OSPF route seems wrong, begin with neighbor adjacency, interface network type, expected LSAs, area membership, metric, and any summary or filter at the boundary. Do not immediately raise administrative distance to force traffic onto another path; that would influence competition between protocols and might conceal an incorrect OSPF topology. For IPv4 and IPv6, be explicit about whether an example uses OSPFv2 or OSPFv3 and which addressing or address-family behavior is configured. An OSPFv3 neighbor’s identifiers should not be mistaken for an IPv4 address.
Separate protocol metric from administrative distance
Two routes learned by the same protocol can be compared using that protocol’s path-selection logic. If the same destination is learned from different route sources, the router may use administrative distance to choose which route source wins, subject to platform rules and route specificity. A longer-prefix match is an even earlier forwarding-table consideration: a more specific route can direct traffic differently from a broad default route, regardless of the metric someone inspected on the default.
Suppose an OSPF-learned route and an EIGRP-learned route reach the same subnet. Do not compare raw OSPF cost to EIGRP composite metric as if they were the same unit. Check the installed route, protocol preference, prefix length and any route-map or administrative-distance adjustment. The CCNA static routes and administrative distance material explains the foundational distinction; ENCOR adds the interplay with dynamic metric computation and selected traffic policy.
Recognize where policy-based routing intervenes
Policy-Based Routing (PBR) can match selected transit traffic and influence its next hop according to a defined policy rather than relying only on the ordinary destination route lookup. This is useful when a subset of traffic needs a service insertion point or an explicitly chosen path. It also introduces another control plane to inspect whenever the observed forwarding path contradicts the route table. An engineer cannot prove a forwarding outcome solely by displaying the global RIB if PBR is active on the ingress interface.
A branch might prefer a security-inspection link for one application’s traffic and ordinary routing for the rest. A route map can identify the permitted source or destination traffic class and set an intended next hop. Before deployment, define what must happen if that next hop becomes unreachable. Without appropriate tracking or platform-specific fallback behavior, traffic can be blackholed or follow an unintended path. The policy-based routing configuration discussion is a related practical reference, but ENCOR requires understanding the selection and its failure consequences rather than memorizing one vendor command sequence.
Troubleshoot a mixed-routing example step by step
Imagine two application servers in different branches, one reached through an MPLS service and one through an internet VPN. The destination prefix is correctly learned by OSPF at both sites, yet one source subnet keeps taking an inspection path. Collect the source address, ingress interface, destination prefix and actual forwarding observation. Check the longest matching route and the relevant OSPF or EIGRP neighbor state, then inspect any PBR route map and access list applied at the ingress point. If policy matches a different flow than expected, changing the OSPF metric will not solve it.
Once the cause is identified, test a normal matched flow and a flow that should bypass PBR. Validate both the forward and reverse paths, especially when stateful firewalls or NAT are involved. If a return flow follows a different device, session state may fail even though each one-way route looks valid. Record how the policy behaves under a simulated next-hop failure before calling the result resilient. A correct route-map syntax check is not the same as proving user traffic survives a transport outage.
Limit redistribution to genuine domain boundaries
At a protocol boundary, redistribution can expose routes between routing domains, but it may also introduce feedback loops or obscure route ownership. A route that leaves EIGRP for OSPF and is later redistributed back without careful policy can appear as an alternate path to its own origin. Use explicit permitted prefixes, tagging where appropriate, documented metric handling and route summaries that do not discard needed reachability. An ENCOR learner should understand why such controls matter without claiming that every complex redistribution scenario is part of the core exam.
Test a routing-domain edge with one route deliberately missing, one deliberately filtered, and one more-specific exception. Confirm which routes appear in each table and that a failure does not create unexpected preference inversions. Detailed loop troubleshooting belongs in the separate ENARSI route-redistribution specialist, so a core-level article should not be inflated into an advanced concentration course for the sake of breadth.
An IPv6 deployment adds an important distinction. OSPFv3 neighbor establishment and route advertisement are not simply an IPv4 adjacency displayed with longer addresses. Verify interface-level IPv6 configuration, link-local neighbor reachability, area membership and expected prefixes as independent facts. If a default route appears only in one address family, verify the correct process and policy instead of assuming the IPv4 settings implicitly created IPv6 behavior. The ENCOR blueprint includes the ability to configure and verify basic multiarea OSPFv2 and OSPFv3, so a controlled two-area IPv6 exercise is useful without extending into every redistribution corner case.
Convergence measurements should also name their observation point. An adjacency can recover before the route is installed in the relevant forwarding table, and an application can recover later still because of session behavior. Capture time-stamped neighbor state, installed route and a representative traffic test. A routing process reporting Full adjacency establishes a relationship between routers, not necessarily usable end-to-end access to the intended application. By measuring these separately, the team can identify whether the remaining delay is in routing, policy, security state, or the application.
Use concise evidence instead of broad configuration changes
For EIGRP, collect neighbor state, successor and feasible-successor information, route metrics and any active computation. For OSPF, inspect adjacency, area, LSDB interpretation, installed routes and path costs. For PBR, find the actual ingress policy, route-map matches, next-hop reachability and forwarding evidence. Those three sets of observations answer different questions; together they explain why the path differs from the network diagram.
A good lab exercise compares the selected route before and after a link failure, then applies a carefully scoped PBR policy and repeats the test with two source subnets. The learner should be able to name the route owner, path-selection method, local forwarding decision and fallback outcome. That discipline is more durable than learning a route command in isolation because it shows where the protocol ends and explicit traffic policy begins.