OSPF and BGP solve different routing problems, but enterprise designs often need both. OSPF provides an interior link-state protocol that can converge quickly and organize routing into areas. BGP provides policy-rich interdomain routing and is well suited to external connectivity, multi-homing, and environments where path control matters more than shortest-path calculation. The Cisco 350-401 ENCOR scope expects engineers to understand OSPF deeply and to work with eBGP path selection in enterprise designs.
Current Cisco ENCOR training emphasizes OSPFv2 and OSPFv3, areas, summarization, route filtering, neighbor formation, and eBGP single- and dual-homed connectivity. The exam-level challenge is not remembering that OSPF uses cost and BGP uses path attributes. It is understanding where each protocol belongs, how its topology should be bounded, and what failure behavior the design creates.
Use OSPF when the network needs an IGP
OSPF is designed to distribute internal reachability. Routers within an area share link-state information and calculate shortest paths using the same topology database. That gives deterministic path selection and fast adaptation when links change, provided the design avoids unnecessary complexity.
The OSPF fundamentals matter because design depends on protocol mechanics. Neighbors must agree on parameters and network types. DR and BDR behavior affects broadcast segments. Passive interfaces can advertise connected networks without forming unnecessary adjacencies. Summarization and filtering must be placed at the correct boundaries.
Area design controls scale: Area 0 is the OSPF backbone. Other areas connect through area border routers. The goal is to reduce how far detailed topology changes must propagate, not to create areas merely because the feature exists. A small network may be best as one area. A large campus or WAN can benefit from multiple areas when topology size, failure scope, and route summarization justify the boundary.
The relationship between OSPF areas and LSAs explains why area boundaries matter. Internal topology details remain within an area while ABRs advertise summarized reachability between areas. Poor area design can add complexity without reducing useful state.
Summarization should reflect address design
Route summarization is easiest when addressing is hierarchical. If every site receives contiguous prefixes, an ABR can advertise one summary instead of dozens of specifics. That reduces routing-table size and isolates instability. If addressing is random, summarization becomes difficult or creates black-hole risk.
Good IP planning therefore precedes routing optimization. A summary should represent reachability that actually exists behind the boundary. Advertising a broad summary while all component networks are unavailable can attract traffic to a dead end unless discard routes and failure behavior are understood.
OSPF path design is about cost and topology: OSPF selects paths based on cost. Engineers can influence cost to prefer links, but manually tuning every interface is not a scalable design. Start with a topology that naturally reflects preferred paths, then adjust cost where business requirements justify it.
Equal-cost multipath can use multiple routes with the same metric. That can increase resilience and capacity, but application flows still follow hashing behavior rather than packet-by-packet balancing in most implementations. Understand the forwarding result instead of assuming two equal routes split traffic perfectly in every instant.
Use BGP when policy matters
BGP is a path-vector protocol designed for routing between autonomous systems. In an enterprise, eBGP often appears at internet edges, partner connections, cloud interconnects, or dual-homed WAN designs. It gives engineers tools to prefer one exit, influence inbound routing, filter accepted prefixes, and control which networks are advertised.
The BGP route-selection process is deliberately policy-oriented. Attributes such as local preference, AS path, MED, and others affect which path is selected. The important design skill is knowing which attribute influences which direction and whether the policy is local to your AS or visible to neighbors.
Local preference and AS-path prepending solve different directions: Local preference is commonly used inside an autonomous system to choose the preferred outbound exit. A higher local preference makes one path more attractive to internal BGP speakers. AS-path prepending, by contrast, makes a route appear longer to external neighbors and can influence inbound traffic when those neighbors respect AS-path length in their policy.
This directionality prevents common design mistakes. Changing an outbound attribute and expecting it to control inbound traffic is a conceptual error. Always ask whose routing decision you are trying to influence.
BGP communities make policy scalable
Communities attach tags to routes so policy can be applied consistently. A provider may let customers mark routes for local-pref changes, blackholing, or regional propagation. An enterprise can use communities internally to classify prefixes by source, business unit, or intended handling.
The BGP communities approach is more scalable than writing separate prefix-based policy for every route. It separates classification from action: tag a route once, then let multiple policies interpret the tag. This is especially useful in large multi-site networks.
Filtering is a safety requirement: BGP can advertise a great deal of reachability very quickly, including routes you never intended to export. Prefix lists, route maps, maximum-prefix controls, and explicit neighbor policy help prevent route leaks. At an internet edge, the enterprise should know exactly which prefixes it accepts and advertises.
OSPF also needs filtering discipline, though the mechanisms and design boundaries differ. Interior protocols are usually trusted more broadly, so a redistribution mistake between OSPF and BGP can be particularly dangerous. Route tagging and controlled redistribution help prevent loops and feedback.
Redistribution is where designs become fragile
Redistributing routes between OSPF and BGP connects routing domains, but it also connects their failure modes. If routes are redistributed both directions without clear policy, the network can create loops, suboptimal paths, or route feedback. Prefer simple, explicit boundaries and advertise only what the other domain truly needs.
Default routes are often better than full redistribution for stub parts of the network. A branch does not need every external BGP path if all internet traffic should leave through one edge. Simpler routing state is easier to troubleshoot and safer to automate.
Fast failure detection should complement routing, not fight it: OSPF hello and dead timers detect neighbor loss, but BFD can provide faster failure detection across supported links and protocols. The BFD design separates rapid liveliness detection from the routing protocol’s own timer behavior. That can improve convergence in high-availability designs.
However, very aggressive timers increase sensitivity to transient loss and device load. Design failure detection to meet the application requirement, then test it under realistic congestion and maintenance conditions.
Dual-homing requires a complete failure story: A dual-homed enterprise edge is not resilient simply because two routers connect to two providers. Ask what happens if one circuit fails, one edge router fails, one provider stops accepting your advertisements, or the internal path to the surviving edge fails. BGP, IGP, first-hop redundancy, and physical topology must agree on the recovery path.
Symmetric routing may matter for stateful firewalls. NAT may bind sessions to one edge. Security inspection may not tolerate unexpected return paths. Routing design therefore has to consider services around the protocol, not just the routing table.
How to solve an ENCOR routing scenario
First identify whether the problem is internal reachability or external policy. For OSPF, inspect adjacency, area, network type, cost, summarization, and route filtering. For BGP, inspect neighbor establishment, accepted and advertised prefixes, path attributes, and the direction of policy. If the problem crosses both protocols, inspect redistribution boundaries and route tagging.
The 350-401 study process should include drawing the expected RIB before looking at command output. If you know which route should win and why, verification commands become evidence. If you do not know the expected state, a long routing table can be misleading.
Neighbor formation problems reveal design assumptions: OSPF adjacencies depend on compatible area IDs, timers, authentication, network type, MTU behavior, and IP reachability. BGP sessions depend on TCP connectivity, correct neighbor addresses, autonomous-system configuration, and often explicit update-source or multihop design. When a neighbor fails, troubleshoot the prerequisite chain before changing route policy.
This matters architecturally because every adjacency is a dependency. A large number of unnecessary neighbors increases operational surface area. Design topologies so each routing relationship has a clear purpose and predictable failure domain.
Route selection and forwarding are not the same thing
A router can learn several candidate routes from OSPF, BGP, static configuration, and connected networks. Administrative distance decides which routing source is preferred when routes to the same prefix compete; protocol-specific metrics then select paths within that source. The winning route enters the RIB and is programmed for forwarding.
Understanding this hierarchy prevents common mistakes. Changing an OSPF cost cannot make OSPF beat a connected route. Changing a BGP attribute cannot influence a static route unless the static route is removed or its administrative distance is altered. Always identify which protocol is currently winning before tuning its internal metric.
iBGP design has scaling consequences: Although ENCOR focuses heavily on eBGP at the enterprise edge, it helps to understand why iBGP can become a scaling issue. A full mesh of iBGP speakers grows rapidly as routers are added. Large networks use route reflectors or other designs to reduce session count, but those choices alter path visibility and troubleshooting.
Even when a scenario is limited to two enterprise edge routers, keep the control-plane question in mind: how do both devices learn external routes, how do internal routers reach the chosen exit, and how does the design avoid one edge becoming a silent black hole?
Default routing can be a deliberate simplification
Not every internal router needs detailed internet or partner prefixes. Advertising a default route from the edge can keep the IGP smaller and make policy easier to understand. The edge routers can retain BGP detail while the campus or branch network simply forwards unknown destinations toward them.
The tradeoff is visibility and path choice. If internal routers need to select among several exits based on destination, a default may be too simple. Architecture should give downstream routers only the information they actually need to make the required decision.
Verify both control plane and data plane: A correct neighbor relationship does not guarantee end-to-end forwarding. Verify the route is present, the expected next hop is reachable, the forwarding table programs the path, return routing exists, and security devices allow the flow. For BGP especially, next-hop reachability can cause a route to remain unusable even when the session is established.
Use ping and traceroute carefully, then correlate them with routing and forwarding state. A protocol command tells you what the control plane believes; a traffic test tells you whether the path actually works. Strong troubleshooting uses both.
What to carry into the exam
Use OSPF as an internal topology protocol with deliberate areas, summarization, and cost. Use BGP where interdomain policy and multi-homing require richer path control. Keep redistribution minimal and explicit, filter advertisements, understand which direction each attribute influences, and design failure detection around business needs. Strong routing design is not about making every protocol present—it is about giving each protocol a clear role and a clean boundary.