Border Gateway Protocol (BGP) is the routing protocol that glues the internet together, making it possible for data to travel between thousands of independently owned networks. Without BGP, your Netflix stream, email, or video call would never leave your own service provider’s network. For the 350-401 ENCOR exam, understanding BGP path selection is non-negotiable: it is the core mechanism that gives network engineers precise control over how traffic enters and leaves their organisation, and it appears in a large number of exam questions.
Jump to a section
A simple way to picture BGP Fundamentals and Path Selection
A network of regional distribution centres run by a national freight company uses multiple independent haulage firms to move parcels between cities. The central scheduler at each depot maintains a master list of available routes, detailing which hauliers connect which depots, how many intermediate sorting offices a parcel will pass through, and the contract cost per consignment. When a parcel must go from Glasgow to Southampton, the scheduler consults a strict policy handbook. First, it checks an internal priority flag set by the depot manager—if one haulier has a higher internal flag, it wins outright. Next, it looks at a group-wide preference score assigned to each haulage partner by head office; the highest score is used. After that, the scheduler favours routes that originate in its own depot. If the decision is still not made, it counts the number of intermediate sorting offices—fewer transshipments are better. The type of route (direct contract, ad-hoc broker, or unknown) then breaks ties. Finally, if a haulage company offers multiple entry points into its network, the scheduler compares the per-mile rate advertised for each entry, choosing the lower one. All these checks happen in a rigid sequence, ensuring every parcel follows the most business-aligned path. This hierarchy—internal flag first, company-wide preference second, shortest transshipment chain third, and cost fourth—mirrors exactly how BGP selects the best path through the internet.
BGP stands for Border Gateway Protocol. It is a path-vector routing protocol—a type of software that decides how data packets should travel from one network to another by looking at the entire sequence of networks (called an AS path) the packet will cross. The internet is built from thousands of separate administrative domains called autonomous systems (ASes). An AS is simply a collection of routers and IP addresses under the control of a single organisation, identified by a unique AS number (ASN). Think of an AS as a single depot in the logistics analogy. BGP’s job is to exchange reachability information between ASes: it tells its neighbours “I know how to reach this block of IP addresses, and here is the list of ASes you must go through to get there.”
BGP operates in two flavours. eBGP (external BGP) runs between routers in different ASes, typically over a direct physical connection. iBGP (internal BGP) runs between routers inside the same AS, allowing them to share the routes they have learned from outside. When an eBGP router advertises a route to an iBGP neighbour, it does not change the next-hop address by default, which can cause problems if the iBGP router does not have a direct route to that external next-hop. This is why features like next-hop-self exist: they tell the advertising router to replace the original next-hop with its own IP address, so the internal router can reach it through the IGP (Interior Gateway Protocol, such as OSPF or EIGRP) already running inside the AS.
BGP does not use raw bandwidth or link speed to pick the best path. Instead, it attaches a set of path attributes to every route and applies a deterministic set of rules—the BGP best path selection algorithm—to choose which route to install in the routing table. The key attributes tested on the ENCOR exam are:
Weight: A Cisco-proprietary value local to a single router. It is the very first tie-breaker; the highest weight wins. Weight is never sent to any BGP neighbour.
Local Preference (Local Pref): A standard, well-known attribute that is propagated to all iBGP routers inside the same AS. It indicates which exit point from the local AS is preferred. The highest local preference wins. The default value in Cisco IOS is 100.
AS Path: A list of AS numbers a route has traversed. Shorter AS paths are generally preferred, but this attribute is only examined after weight and local preference.
Origin: Indicates how the route was originally introduced into BGP. The three origin codes, in order of preference, are IGP (most preferred, indicating the route was learned from an internal gateway protocol), EGP (the old Exterior Gateway Protocol), and Incomplete (?).
MED (Multi-Exit Discriminator): A metric that tells a neighbouring AS which entry point into your AS is preferred when the neighbour has multiple links to you. Lower MED is better. MED is only compared when routes come from the same neighbouring AS; if they come from different ASes, MED is ignored in the path selection.
BGP routers store all received routes in the BGP table, which can hold multiple paths for the same prefix. Only the best path, as determined by the algorithm, is offered to the IP routing table and advertised to peers. The full Cisco BGP path selection order is:
Highest weight
Highest local preference
Routes originated locally (via the network or aggregate-address command, or through redistribution)
Shortest AS path
Lowest origin type (IGP preferred over EGP, then Incomplete)
Lowest MED (compared only if paths are from the same neighbouring AS)
eBGP over iBGP (an external path is preferred to an internal one)
Lowest IGP metric to the BGP next-hop
If all the above are equal, prefer the oldest eBGP route
Lowest router ID (or originator ID if route reflector is used)
Lowest neighbour address
BGP exists because the Interior Gateway Protocols like OSPF and EIGRP are designed to operate inside a single administrative domain and scale to maybe a few thousand routes. The global internet carries nearly a million prefixes and must support policy-based routing—allowing each AS to make business-driven decisions about which path its traffic takes. BGP replaces the need for a monolithic, flat routing system that would collapse under the weight of that many routes, by organising the internet into manageable, independently administered chunks that can enforce traffic contracts.
Inject routes into BGP table
A BGP router learns prefixes either from directly connected networks announced with the network command, from redistribution of IGP routes, or from BGP updates received from its peers. Each prefix may have multiple paths stored in the BGP table. This step matters because BGP can only select a best path among the routes it actually knows about.
Compare Weight (Cisco-specific)
For every prefix, the router looks first at the weight attribute, a number that can be assigned via route maps on incoming updates or set globally. The path with the highest weight is chosen immediately. Weight is never advertised, so its effect is purely local. This step is critical on ENCOR because Cisco routers always evaluate weight first, and a high weight can override every other attribute.
Compare Local Preference
If multiple paths remain after the weight step (most often because no weight was set, default zero), the router examines the local preference attribute. This value is a well-known discretionary attribute that is included in all iBGP updates and influences how all routers in the same AS view the path. The local preference with the highest value wins. This is the primary tool for setting AS-wide exit policies.
Evaluate locally originated routes, AS path length, and origin type
If local preference is tied, the router prefers routes that were originated on the local device (via network, aggregate-address, or redistribution). Next, it picks the path with the shortest AS path list. After that, it checks the origin code: IGP (least preferred number) is better than EGP, which is better than Incomplete. These three checks form the core of the standard BGP decision process and are frequently tested in show ip bgp output interpretation.
Examine MED, eBGP vs iBGP, and IGP metric
With all earlier attributes equal, the router compares MED if the neighbouring AS is identical across paths; lower MED is preferred. It then prefers an eBGP-learned route over an iBGP-learned route. Finally, it selects the path whose next-hop BGP address can be reached through the IGP with the lowest metric. These steps handle multi-exit scenarios and tie-breaking based on internal topology.
Apply final tie-breakers
When all the above are equal, Cisco applies additional tie-breakers: choose the oldest eBGP route (for stability); if still tied, choose the path with the lowest router ID (or originator ID if a route reflector is in use); as a last resort, the lowest neighbour IP address. Understanding this last chain ensures you can identify the winner in laboratory or exam scenarios where everything else appears identical.
Picture an enterprise called MegaCorp that owns the public IP address block 203.0.113.0/24. MegaCorp wants internet connectivity that is both fast and resilient, so it buys two internet connections: a high-speed fibre link from ISP-A and a cheaper backup link from ISP-B. Both ISPs agree to run eBGP with MegaCorp’s edge router. To achieve the desired traffic flow—outbound traffic should normally use ISP-A, inbound traffic should also prefer ISP-A—the network engineer takes the following steps.
First, eBGP peering is configured. The engineer defines a BGP process on MegaCorp’s router with the local AS number 65001, and configures two neighbours: ISP-A’s router (AS 1111) and ISP-B’s router (AS 2222). Once the sessions reach the Established state, each ISP starts sending the full internet routing table—or, more practically for this small setup, a default route—through BGP updates.
To control outbound traffic, the engineer uses the local preference attribute. A route map is applied to ISP-A’s incoming updates that sets the local preference to 200, while ISP-B’s updates retain the default of 100. Because local preference is compared early in the decision process, the router will install ISP-A’s path as the best route for all destinations, sending all packets out of the fibre link under normal conditions.
Inbound traffic is trickier because MegaCorp cannot directly set the ISP’s path selection. However, BGP provides tools. The engineer configures AS path prepending on the advertisement sent towards ISP-B. Normally, MegaCorp announces its prefix 203.0.113.0/24 with an AS path of “65001”. By prepending, the path becomes “65001 65001 65001”, making it appear three AS hops away instead of one. When ISP-B propagates this to the rest of the internet, other networks see a longer AS path and will choose the path through ISP-A, which has the shorter path, as their best route. The engineer might also set a MED value on the route advertised to ISP-A if ISP-A offers two connection points, but in this dual-homed scenario MED is less powerful because the ASes are different.
In the monitoring phase, the engineer uses commands like show ip bgp, show ip bgp summary, and show ip bgp 203.0.113.0/24 to verify that the correct paths are selected and that traffic flows as intended. If the fibre link fails, BGP will detect the loss of the eBGP session, withdraw the ISP-A routes, and fall back seamlessly to ISP-B—achieving the resilience MegaCorp requires.
The 350-401 ENCOR exam tests BGP fundamentals and path selection to a depth that goes beyond simple memorisation. You must be able to interpret BGP table output, identify which path will be chosen given a set of attributes, and predict the effect of common configuration changes.
Key exam topics include:
BGP neighbour states (Idle, Connect, Active, OpenSent, OpenConfirm, Established) and what causes sessions to get stuck in each
The four BGP message types: Open, Update, Keepalive, Notification
The difference between eBGP (TTL=1, modifies next-hop by default) and iBGP (TTL=255, does not change next-hop, requires full mesh or route reflectors)
The global BGP best path selection order, with an emphasis on the priority of weight (Cisco-specific), local preference, and AS path length
How MED influences inbound traffic only when multiple links exist to the same neighbouring AS, and why it is often compared late in the selection
Techniques to manipulate traffic: route maps that set local preference, weight, MED, or apply AS path prepending, and the use of BGP communities for large-scale policy
Route reflector concepts: why full-mesh iBGP is impractical, how a route reflector breaks the split-horizon rule, and the roles of originator ID and cluster list to prevent loops
Next-hop-self and why it is essential when iBGP peers do not have a direct route to the external next-hop
The difference between ‘network’ statement (injects a route only if an exact matching IGP route exists) and ‘redistribute’ (which can inject routes with origin Incomplete)
Common trap patterns include:
Presenting a table of paths and asking which one will be selected, while hiding that one path has a higher weight or local preference despite a longer AS path
Mixing paths from different neighbouring ASes and expecting MED to be compared, when in reality MED is only considered if the neighbouring AS is the same for all paths
Confusing weight (local to a router, not advertised) with local preference (propagated within the AS)
Offering a scenario where an eBGP and an iBGP path tie on all earlier attributes, then requiring you to know that eBGP is preferred over iBGP
Using the wrong tie-break point, such as router ID, when the question assumes bgp bestpath compare-routerid is not configured
Expect drag-and-drop questions where you reorder the path selection steps, and simulation items that ask you to interpret show ip bgp output and identify why a particular path was selected. Memorise the sequence from highest weight to lowest router ID, and practise identifying the winner in multi-path scenarios.
BGP is a path-vector protocol that exchanges network reachability information between autonomous systems, using a list of attributes to determine the best path.
Cisco’s BGP best path selection starts with the highest weight (a local, vendor-specific value), followed by highest local preference, then locally originated routes, then shortest AS path, and continues through a strict order ending with tie-breakers like lowest router ID.
Local preference is a standard, well-known attribute propagated to all iBGP peers inside an AS, making it the primary tool for controlling outbound traffic from the entire autonomous system.
MED (Multi-Exit Discriminator) influences incoming traffic but is only compared when multiple paths share the same neighbouring AS; if the neighbouring ASes differ, MED is ignored.
eBGP sessions normally require directly connected neighbours and change the next-hop address to the local router, while iBGP sessions can span multiple hops and leave the next-hop unchanged by default, often requiring the next-hop-self configuration.
The iBGP split-horizon rule prevents a router from advertising routes learned from one iBGP neighbour to another, which is why a full mesh of iBGP sessions—or the use of route reflectors—is mandatory within an AS.
AS path prepending artificially lengthens the AS path list on advertisements sent to a less preferred peer, steering incoming traffic away from that path without changing any other attribute.
Weight is never transmitted in BGP update messages, local preference is included, and both are evaluated before AS path length, making them powerful for traffic engineering even when the AS path would suggest a different route.
These come up on the exam all the time. Here's how to tell them apart.
eBGP
Neighbours are in different ASes
Default TTL is 1, usually requires direct connection
Changes BGP next-hop to its own IP by default
iBGP
Neighbours are in the same AS
Default TTL is 255, can span multiple hops
Leaves next-hop unchanged unless next-hop-self is used
Weight
Cisco-proprietary attribute, not in BGP standard
Locally significant; never sent to any neighbour
Checked first in Cisco’s best path algorithm
Local Preference
Standard well-known discretionary attribute
Propagated to all iBGP peers inside the local AS
Checked second; controls exit point for the whole AS
MED
A metric sent to a neighbouring AS to suggest entry point preference
Lower value is preferred and comparison happens only when neighbouring AS is identical
Useful when connecting to the same ISP via multiple links
AS Path Prepending
A technique of artificially lengthening the AS path list by adding dummy AS numbers
Makes the path appear longer and therefore less attractive to other networks
Useful for influencing inbound traffic when connected to different ISPs
BGP
Path-vector protocol that works between autonomous systems
Selects best path based on policy attributes, not just link cost
Converges slowly, designed for massive scale and stability
OSPF
Link-state Interior Gateway Protocol that works inside a single AS
Selects best path based on cumulative interface cost
Converges quickly (seconds) for fast failover within an enterprise
Origin IGP
Generated by ‘network’ or ‘aggregate-address’ commands
Most preferred origin type (code i) in path selection
Indicates the route came from an IGP and is fully under the AS’s control
Origin Incomplete
Generated by redistribution into BGP (code ?)
Least preferred origin type; often appears for routes learned from a different protocol
May be treated with less trust in some policy frameworks
Next-hop-self enabled
The advertising router substitutes its own IP for the original next-hop
Ensures iBGP peers always reach the next-hop via the IGP, avoiding recursive lookup failures
Often required in iBGP setups where the external next-hop is not known internally
Unchanged next-hop (default iBGP)
The BGP next-hop remains the address of the eBGP router that first learned the route
All iBGP routers must have a valid route (usually via IGP) to that external next-hop
Simplifies design in small topologies with direct IGP reachability to the border router
Mistake
BGP is only used by internet service providers; enterprises never need it.
Correct
Any organisation that wants to connect to two or more external networks and have control over inbound or outbound traffic can use BGP, especially for multi-homing or for connecting to cloud providers.
Beginners often associate BGP exclusively with the global internet backbone because they first learn about it in the context of ISP peering. In practice, many medium-sized companies run eBGP with their ISPs and even use iBGP internally in MPLS VPN designs.
Mistake
The shortest AS path is always chosen as the best route.
Correct
AS path length is only the fourth comparison point in Cisco’s BGP path selection. Weight, local preference, and locally originated routes all take priority over a shorter AS path.
Course material often over-simplifies by saying BGP is a path-vector protocol that prefers fewer AS hops. The exam deliberately presents scenarios where a longer AS path wins because local preference or weight is higher, catching people who memorise the rule in isolation.
Mistake
MED works like a standard metric and is always compared when present.
Correct
MED is only compared when the routes under consideration come from the same neighbouring autonomous system. If they originate from different ASes, the MED values are ignored entirely in the best path selection.
Most routing protocols compare a metric for all paths. BGP’s design limits MED comparison to a single neighbouring AS to avoid globally comparing values that might have different meanings from different providers. This catches many exam takers who apply IGP logic to BGP.
Mistake
Weight is a standard BGP attribute you can use to influence path selection in any BGP implementation.
Correct
Weight is a Cisco-proprietary value that exists only locally on the router where it is set. It is never communicated to any BGP neighbour and has no equivalent in the BGP standard.
Training materials often lump weight together with local preference without clearly marking weight as vendor-specific. People then try to use weight in multi-vendor environments or expect it to appear in BGP update messages, which it never does.
Mistake
BGP converges as quickly as OSPF or EIGRP, so you can use it for fast failover inside a data centre.
Correct
BGP is designed for stability and policy, not speed. Convergence can take several seconds or longer because of the need to process thousands of routes and dampen flapping. For fast sub-second failover, protocols like OSPF or BFD (Bidirectional Forwarding Detection) are used in combination with BGP.
New learners see BGP as just another routing protocol and assume similar convergence properties. The ENCOR exam expects you to know that BGP’s decision-loop avoidance mechanisms (like route flap damping and minimum advertisement intervals) deliberately slow it down.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
eBGP runs between routers in different autonomous systems, usually over a direct connection with a time-to-live of 1, and changes the BGP next-hop to its own address by default. iBGP runs between routers in the same AS, can span multiple hops, does not change the next-hop unless next-hop-self is configured, and requires a full mesh of sessions or route reflectors because of the split-horizon rule.
BGP uses a deterministic algorithm that compares attributes in strict order: highest weight (Cisco), highest local preference, locally originated routes, shortest AS path, lowest origin type, lowest MED (only if same neighbouring AS), eBGP over iBGP, lowest IGP metric to next-hop, oldest eBGP route, lowest router ID, and finally lowest neighbour address.
The AS_PATH lists every autonomous system a route has traversed. It serves two main purposes: loop prevention (a router discards routes that contain its own AS number) and path selection (shorter AS_PATH is generally preferred, though other attributes can override it). It also gives engineers the ability to influence inbound traffic by prepending additional AS numbers.
A full mesh of iBGP peers becomes unmanageable as the number of routers grows because every router must peer with every other. A route reflector relaxes this requirement by allowing designated reflectors to re-advertise iBGP-learned routes to clients, while still preventing loops through the addition of the originator ID and cluster list attributes.
You typically manipulate the BGP attributes you advertise to your ISPs. The most common technique is AS path prepending, where you add extra copies of your own AS number to the AS_PATH advertised towards the less preferred ISP, making that path appear longer. With two connections to the same ISP, you can use MED to set a lower metric on the preferred link.
The next-hop-self command forces an eBGP or iBGP speaker to replace the original BGP next-hop address of a route with its own IP address when advertising that route to an iBGP neighbour. This ensures the receiving router always has a reachable next-hop via the IGP, which is essential when the original next-hop belongs to an external network not known to the IGP.
MED is designed to be a hint from a neighbouring AS about multiple entry points into that same AS. If the paths come from different neighbouring ASes, the MED values were set by different organisations with potentially different policies, so comparing them would be meaningless and could lead to unpredictable routing decisions.
You've finished BGP Fundamentals and Path Selection. Continue through the 350-401 ENCOR study guide to build a complete picture of the exam.
Done with this chapter?