Network Insight · Interactive Learning Centre
BGP Learning Centre: Explore. Trace. Diagnose.
Learn Border Gateway Protocol through interactive network engineering labs. Explore autonomous systems, trace route propagation, compare competing paths, and investigate routing failures. See how BGP behaves, one experiment at a time.
Explore BGP Through Interactive Engineering Labs
Border Gateway Protocol (BGP) enables networks to exchange routing information across the internet. To understand how it works, you need more than memorised path attributes. You need to see how autonomous systems connect, how routes propagate, how routing decisions are made, and what happens when a network fails.
This learning centre takes you through four practical stages. Each combines an engineering explanation with an interactive network model, allowing you to explore routing behaviour, examine the evidence, and understand why BGP reaches a particular outcome.
You will investigate autonomous system relationships, trace route advertisements, compare competing paths, and diagnose routing failures using the reasoning applied in real network environments.
Your learning journey: Understand the topology → Trace route propagation → Explain the best path → Investigate the failure.
Your learning pathway
Explore the BGP Learning Labs
Follow four practical stages, from understanding the network topology to diagnosing routing failures. Select a stage to jump directly to its explanation and interactive lab.
BGP Route Reflectors Explained
Discover how route reflectors solve the iBGP full-mesh problem, control route propagation, and use ORIGINATOR_ID and CLUSTER_LIST for loop prevention. Explore the architecture, route distribution rules, and troubleshooting evidence behind scalable BGP network designs.
Explore an Interactive BGP Network Topology
Inside a BGP Network
Explore six routers across three autonomous systems. Trace a route advertisement, compare candidate paths, inspect BGP sessions, and investigate a simulated failure.
Architecture: three autonomous systems
AS65001 contains R1, RR1, R4 and R5. AS65002 and AS65003 represent external autonomous systems. Inspect any element to explore its role.
Network architecture
Select a router, AS boundary, or connection to inspect its function, peers, and protocol role.
BGP Architecture: Autonomous Systems, Routers and Peering
BGP Learning Centre · Foundation 01
Understanding the Network Structure
The Border Gateway Protocol (BGP) is the routing protocol used to exchange reachability information between autonomous systems across IP networks. To understand how BGP behaves, start with the architecture: which network a router belongs to, which peers it exchanges routes with, and how those routes influence forwarding.
Autonomous systems
An autonomous system (AS) is a network or group of networks operated under a common routing policy. Its Autonomous System Number (ASN), such as 65001, identifies it in BGP.
BGP peers
BGP speakers establish sessions with configured neighbors. Once a session is established, they can exchange route advertisements and withdrawals, subject to routing policy.
Routes and forwarding
BGP helps select paths to destination prefixes. The selected route influences the routing table and, when usable, the forwarding information installed for packet delivery.
eBGP and iBGP: two different relationships
The ASNs on either side of a BGP session determine whether the relationship is external or internal.
Between autonomous systems
eBGP exchanges routing information between BGP speakers in different autonomous systems. It is commonly used between providers, customers, and peers at network boundaries.
Within one autonomous system
iBGP distributes BGP routing information between speakers in the same AS. Its design must account for propagation rules, next-hop reachability, and mechanisms such as a full mesh or route reflectors.
Important engineering principle: an iBGP session does not automatically make every route learned from one iBGP peer available to every other iBGP peer. By default, a route learned through iBGP is not re-advertised to another iBGP peer. A valid design must address this constraint.
Reading the learning topology
In the interactive topology below, follow each router's AS membership and its configured connections. A link represents a relationship between routers; its meaning depends on whether the peers belong to the same or different autonomous systems and how the BGP session is configured.
| What to inspect | Engineering question |
|---|---|
| Router and ASN | Which autonomous system does this router belong to? |
| Neighbor relationship | Is the session eBGP or iBGP, and is the neighbor established? |
| Advertised prefix | Which destination network is being announced, and where can the advertisement propagate? |
| Selected route | Which candidate path is preferred, and what attributes explain the decision? |
Control plane versus data plane: BGP operates in the control plane, exchanging routing information and helping determine preferred paths. The data plane forwards packets using installed forwarding entries. A route appearing in BGP does not, by itself, prove that end-to-end traffic can pass.
Next: Explore the topology. Select routers, inspect their ASNs and relationships, and trace how the learning environment represents connectivity. Treat the diagram as a teaching model; real deployments also require correct addressing, session configuration, routing policy, and next-hop reachability.
Explore a Multi-AS BGP Topology
Explore the master six-router topology across three autonomous systems. Inspect the route reflector, internal and external BGP sessions, and the illustrative prefix 10.10.10.0/24. This is an educational model, not a live network.
One topology, three autonomous systems
Select an AS, router or connection to inspect its role in the master topology.
A session does not prove that a route is advertised, accepted, selected or installed in the forwarding table.
Understand route reflection
RR1 reflects eligible routes between its iBGP clients. The topology separates control-plane sessions from the underlay.
R1–R4 is an underlay connection only. It must not be counted as a BGP session.
Step 1 · Prefix origin
Follow the illustrative prefix from R2 through the BGP topology. Each advertisement remains subject to route eligibility and policy.
Inspect connection
Inspect the connection type and its endpoints.
Check session state, route source and applicable policy.
Simulated BGP session fault
Mark one of the five BGP sessions as failed in this illustration. No real network tests are performed.
Check reachability, peer state, route receipt, policy and best-path selection. A simulated failure does not calculate convergence.
BGP Route Reflector Design: Scaling iBGP Beyond the Full Mesh
As an autonomous system grows, maintaining an iBGP session between every pair of routers becomes increasingly difficult. Route reflectors provide a scalable alternative: selected routers distribute eligible BGP routes to other iBGP peers, reducing the number of sessions needed while preserving the control-plane architecture of BGP.
1. Why a full mesh becomes a problem
Traditional iBGP rules prevent a route learned from one iBGP peer from being advertised to another iBGP peer. To ensure that internal routers can learn routes from one another, a conventional design therefore requires a full mesh of iBGP sessions.
Every router must establish a session with every other router in the same iBGP mesh. As the number of routers increases, the number of sessions grows rapidly.
For a full mesh of n routers, the number of unique iBGP sessions is n × (n − 1) ÷ 2. Five routers require 10 sessions; 20 routers require 190.
2. How route reflectors change the design
A route reflector (RR) is an iBGP speaker configured to reflect eligible routes between its peers. Routers configured as route-reflector clients establish iBGP sessions with the reflector rather than requiring a direct session with every other client.
The reflector receives routes, evaluates them according to BGP processing and policy, and advertises eligible routes to clients and, where the reflection rules permit, non-client peers. This reduces the full-mesh session requirement.
Full-mesh iBGP
Every router peers with every other router. This is straightforward in small networks but can create substantial session and configuration overhead at scale.
Route reflector
Clients peer with a reflector that distributes eligible routes. Fewer sessions are required, but reflector placement, redundancy and policy become important design decisions.
Conceptual only: the reflector maintains sessions with its clients and can also peer with non-clients. The exact design depends on the network's topology, routing policy and redundancy requirements.
3. Understand the route-reflection rules
Route reflection changes the normal iBGP advertisement restrictions. It does not mean that every route is automatically sent to every peer.
- Route learned from a client: the reflector can advertise it to other clients and to non-client peers, subject to BGP route selection and policy.
- Route learned from a non-client peer: the reflector can advertise it to clients, but does not normally reflect it to other non-client peers.
- Route learned from an eBGP peer: the reflector can advertise an eligible route to clients and non-client iBGP peers, subject to normal processing and policy.
4. Preventing loops with reflection attributes
Reflection introduces additional paths by which routing information can circulate. BGP uses specific attributes to help prevent a reflected route from returning to places it has already passed through.
| Attribute | Design purpose |
|---|---|
| ORIGINATOR_ID | Identifies the originating BGP router ID for a reflected route. A router receiving a route with its own router ID as the originator can reject it to prevent a loop. |
| CLUSTER_LIST | Records route-reflector cluster IDs traversed by a reflected route. A reflector can reject a route if its own cluster ID is already present. |
5. What makes a robust route-reflector design?
- Redundancy: consider multiple route reflectors so that a single reflector failure does not remove the only path for distributing internal routing information.
- Client placement: assign clients deliberately and maintain clear, consistent peering relationships.
- Policy consistency: understand how filtering, attributes and route selection affect what the reflector can advertise.
- Next-hop reachability: a reflected route can be present in the BGP table while its next hop is unusable.
- Forwarding validation: confirm that the selected route is installed in the routing and forwarding tables when traffic delivery is the objective.
BGP Route Reflector Design Lab
Compare a traditional iBGP full mesh with a route-reflector architecture. Select a route source and destination, trace the illustrative advertisement path, and explore the rules that govern route reflection.
1. Choose the iBGP architecture
Topology view
Full meshThis example uses five routers in one AS: three clients, one route reflector, and one non-client peer.
2. Trace a route advertisement
Choose a source and destination to inspect the route path.
- Select a source and receiving router.
- Choose the architecture.
- Trace the illustrative advertisement path.
3. Understand the route-reflection rules
The reflector can advertise the route to other clients and to non-client peers, subject to normal BGP eligibility and policy.
The reflector can advertise the route to its clients. It does not normally advertise a route learned from one non-client to another non-client.
RR1 can advertise its locally originated route to its clients and non-client peers, subject to normal BGP rules and policy.
A direct session does not bypass iBGP split-horizon rules. A router does not normally re-advertise a route learned from one iBGP peer to another iBGP peer.
4. Inspect route-reflection attributes
ORIGINATOR_ID
Identifies the originator's BGP router ID for a reflected route. A route reflector adds it when appropriate, helping prevent a reflected route from returning to its originator.
CLUSTER_LIST
Records route-reflector cluster IDs traversed by the route. A reflector checks this attribute to help detect and prevent reflection loops involving its cluster ID.
5. Knowledge check
Why do engineers deploy route reflectors in larger iBGP networks?
Engineering note: This is an illustrative control-plane model, not a live BGP implementation. Session counts assume five routers and one route reflector with four client/non-client peer sessions: 10 sessions in a full mesh versus 4 in the reflector design. Real deployments may use multiple reflectors and redundant clusters. Route reflection does not guarantee route selection, next-hop reachability, FIB installation, or end-to-end connectivity.
BGP Learning Centre · Stage 01 Complete
What You Have Learned
Before tracing a route through a network, you need to understand the architecture that carries it. These are the foundations for interpreting BGP sessions, route advertisements, and forwarding decisions.
Three concepts to remember
Know the AS boundary
An autonomous system operates under a common routing policy. Its ASN identifies it in BGP. The relationship between the local and remote ASNs helps determine whether a session is eBGP or iBGP.
Separate links from sessions
A physical or logical connection provides connectivity, but it does not prove that a BGP session is established. Neighbor configuration, reachability, and successful session negotiation all matter.
Separate routes from packets
BGP exchanges reachability information and helps select paths. Actual packet delivery depends on usable forwarding entries, next-hop reachability, and the state of the data plane.
Engineering principle
Connectivity is not the same as reachability. A router can have a working link without an established BGP session, and an established session does not guarantee that a usable route or working end-to-end forwarding path exists.
BGP Route Propagation: How Prefixes Travel Through a Network
Following a Route Advertisement
A prefix does not automatically appear in every router's BGP table. It must be originated or learned, advertised to an eligible peer, accepted under routing policy, and processed according to BGP's propagation rules. Follow the evidence at each stage to understand where a route continues — and where it stops.
A working connection is not proof of route propagation. Even an Established BGP session does not prove that a particular prefix was advertised, accepted, selected or installed for forwarding.
The route lifecycle · Four stages
Originate or learn
A router introduces a prefix into BGP or learns it from an existing BGP neighbor.
Prefix availableAdvertise
The router sends an UPDATE to an eligible peer when protocol rules and export policy permit it.
Advertisement sentEvaluate
The receiving router processes the route, applies import policy and evaluates its eligibility.
Route assessedSelect and propagate
An eligible route may be selected and advertised onward if policy and BGP rules allow it.
Outcome depends on rulesThis is a conceptual route progression, not a claim that every adjacency will pass the prefix. For example, if R2 learns a route from an iBGP peer, it normally cannot advertise that route to another iBGP peer unless the design uses an appropriate mechanism, such as route reflection. The actual outcome depends on the configured topology, route eligibility and policy.
When eBGP advertises a route
When a route is advertised to an external BGP peer, the advertising router normally adds its AS number to AS_PATH. Import and export policy may permit, reject or modify the route. The receiving AS must evaluate the advertisement under its own policy.
When iBGP distributes a route
By default, a route learned from one iBGP peer is not re-advertised to another iBGP peer. A full mesh or a mechanism such as route reflection is needed to distribute routes appropriately within the AS. Next-hop reachability also matters.
Route propagation investigation checklist
Use this checklist when a prefix is missing at an expected router. Tick each check as you work through the evidence.
BGP Learning Centre · Foundation 02
How BGP Routes Propagate
BGP does not carry user traffic itself. It exchanges information about which IP prefixes are reachable and the paths available to reach them. Each router processes received routes, applies routing policy, and determines which routes can be selected and advertised to other peers.
Follow a route advertisement
Consider the example prefix 10.10.10.0/24. These four stages describe the general route lifecycle. The actual outcome depends on topology, session state, routing policy, and configuration.
Prefix
The prefix identifies the destination network. The prefix length matters: 10.10.10.0/24 represents a more specific network than 10.10.0.0/16.
Path attributes
Attributes such as AS_PATH, LOCAL_PREF, MED, and communities carry information used in path selection and routing policy. Their significance depends on the attribute and where it is evaluated.
Next hop
NEXT_HOP identifies the next-hop address for reaching the destination. The receiving router must be able to resolve that next hop for the route to be usable for forwarding.
Why routes do not always travel through every router
Across AS boundaries
When a route is advertised across an eBGP session, the advertising router normally adds its own AS number to AS_PATH. Import and export policies can permit, modify, or reject the route.
Inside an AS
A route learned from one iBGP peer is not normally advertised to another iBGP peer. Designs commonly use a full mesh or route reflectors to distribute routes while respecting BGP loop-prevention rules.
Key distinction: physical connectivity is not the same as route propagation. Two connected routers may not exchange a prefix because a session is down, policy rejects the route, the route is ineligible for advertisement, or an iBGP propagation rule prevents it.
When a route is missing, check these four things
Withdrawals matter too: when a route is no longer available or advertised, BGP can send a withdrawal so the peer removes that path from its routing information. An alternative may then be selected if one is available and eligible.
Next: Trace the route. Use the interactive propagation stage to follow 10.10.10.0/24, observe how the learning model represents route updates, and identify where topology or policy changes the outcome. This is a simplified teaching model, not a complete implementation of every BGP protocol rule.
BGP UPDATE Message Inspector
Inspect what a BGP speaker communicates to a peer. Switch between a route announcement, a withdrawal and an attribute change, then reveal the message fields one step at a time.
1. Choose an UPDATE scenario
Router A advertises a reachable prefix to Router B.
2. Reveal the message fields
None
What is happening?
Router A is advertising the prefix 198.51.100.0/24. Router B receives the UPDATE and evaluates the route against its own BGP policies and selection process.
Engineering interpretation
An announcement tells the peer about a prefix and supplies the path attributes used to evaluate it. Receiving an UPDATE does not guarantee that the route will be accepted, selected or installed in the forwarding table.
Knowledge check
In a route announcement, where is the newly advertised prefix represented?
Educational model only. The examples simplify BGP UPDATE processing; actual message encoding, attributes and route handling depend on the address family, negotiated capabilities, implementation and routing policy.
BGP Route Policy Workbench
Change an import policy and see how it affects a received route. Permit or reject a prefix, adjust its local preference, and inspect the resulting routing decision.
Your simulated routing environment
Configure the policy
Router B evaluates a route received from Router A. Change the settings and apply the policy.
Select the prefix Router B receives.
Higher values are generally preferred within the same AS, when comparing eligible routes.
What is Router B checking?
A route must pass the relevant import policy and meet the requirements for further use.
This workbench models a single route and simplified policy logic. Local preference is assigned inside Router B's AS; it is not an attribute normally sent to the external peer.
Routing decision
Ready to evaluateConfigure your policy and apply it to see the result.
Knowledge check
Router B receives a prefix, but its import policy rejects it. What is the expected result?
Illustrative training model, not a live router or vendor-specific policy simulator. Actual route processing depends on policy configuration, address family, route validity, next-hop resolution and the implementation's selection rules.
Follow a BGP Route Across Autonomous Systems
Follow the illustrative prefix 10.10.10.0/24 from R2 in AS65002, into AS65001 through R1, through the RR1 route reflector, and towards R3 in AS65003. Select a router, AS boundary, link or timeline step to inspect the route.
R2 originates the prefix
R2 represents the origin of the illustrative route in AS65002.
Illustrative learning model, not live router output.
What changes as the route moves?
Values describe the example at the receiving stage; they are not live router-table data.
Attribute behavior depends on route origin, session type and configuration.
Propagation timeline
Select any step to jump directly to its explanation.
BGP Route Withdrawal and Convergence
Routing is not only about learning new paths. A network must also respond when a previously advertised route becomes unavailable. BGP communicates route changes between peers, evaluates the paths that remain eligible, and allows the routing and forwarding systems to adjust to the new state.
1. What is a BGP route withdrawal?
A BGP speaker can advertise reachability to a network prefix through an UPDATE message. If that previously advertised route is no longer available through the advertising speaker, the speaker can send an UPDATE that withdraws the prefix.
For example, suppose a router has advertised 10.10.10.0/24 to a BGP peer. If the route becomes unavailable, the peer needs to stop treating that advertisement as a valid path. The withdrawal communicates that the previously advertised reachability should no longer be used from that peer.
2. What happens after a route disappears?
Consider a destination that can be reached through two possible paths. If the primary path is withdrawn, the receiving router processes the change and considers the remaining eligible routes according to BGP decision rules and local routing policy.
If an eligible alternative exists, the router may select it and update its forwarding information. If no usable route remains, reachability to the prefix may be lost. Other routers must process the resulting changes in turn, so the network does not necessarily reach its final state all at once.
3. Why convergence takes time
BGP convergence describes the process through which routing information changes and routers settle on the routes available under the new network conditions. Its duration depends on more than the UPDATE message itself.
| Factor | Why it matters |
|---|---|
| Failure detection | A physical link failure, a BGP notification, or a session timeout may each reveal a problem differently. |
| Route availability | A usable alternative may allow traffic to move to another path; without one, the destination may become unreachable. |
| Routing policy | A candidate route may exist but be rejected or considered ineligible under import policy or other routing constraints. |
| Propagation and processing | Different routers receive and process changes at different times, and may temporarily hold different routing views. |
| Forwarding updates | The forwarding plane must reflect the applicable routing decision; this is related to, but distinct from, receiving a BGP UPDATE. |
4. A route withdrawal is not the same as a session failure
A BGP withdrawal can remove a prefix while the BGP session remains established. A session failure is different: the peers lose their BGP relationship, and routes learned through that session are generally removed from consideration unless retained by a feature such as Graceful Restart under its applicable rules.
This distinction matters during troubleshooting. A session can remain established while a specific route disappears because of a withdrawal or policy change. Conversely, a session failure can affect many routes learned through that peer.
5. From the BGP control plane to the forwarding plane
Learning about a withdrawal is only one part of the process. For traffic to use a replacement path, the router must have a suitable route and be able to resolve the necessary next hop. The routing information base (RIB) and forwarding information base (FIB) serve different purposes: the RIB holds routing information and decisions, while the FIB provides the information used to forward packets.
A successful control-plane update does not by itself prove that end-to-end traffic is flowing correctly. A next-hop resolution problem, forwarding programming issue, or downstream failure can still interrupt connectivity.
Engineering takeaway
When a BGP route disappears, investigate four questions: Was the route withdrawn? Is another path eligible? Has the routing decision changed? Is the forwarding plane using a working path? These checks separate route propagation, path selection and actual forwarding.
Put the timeline into practice
Use the interactive lab that follows to step through two outcomes: a withdrawal where an alternative path is available, and a withdrawal where no usable alternative remains. Watch how the modeled route state changes at each stage.
BGP Route Withdrawal & Convergence Timeline
Withdraw a route or simulate a failed BGP path. Step through the control-plane events and see whether an alternative route can preserve reachability.
Network state
Primary activeR4 has a usable primary path in the starting state.
Event 1: Primary route active
R4 currently uses the route learned along the primary path. An alternative candidate is available in this scenario.
Convergence timeline
1 of 5- 1Primary route activeThe prefix is reachable over the primary path.
- 2Failure or withdrawalThe primary route becomes unavailable.
- 3Route update processedThe router processes the withdrawal or detects the failed session.
- 4Alternative evaluatedA remaining candidate is evaluated, if one exists.
- 5Forwarding state updatedThe usable path changes, or reachability is lost.
Knowledge check
Does receiving a BGP withdrawal mean that every router in the network changes its forwarding table at exactly the same instant?
BGP Learning Centre · Stage 02 Complete
What You Have Learned
A route does not magically appear throughout a network. It must be originated or learned, advertised to eligible peers, accepted under routing policy, and processed according to BGP's propagation rules. Understanding each step helps explain where reachability succeeds or breaks down.
Three concepts to remember
Routes begin with an advertisement
A prefix must be made available to BGP, for example through network configuration or redistribution. BGP can then advertise eligible reachability information to a peer when the session, route state, and policy allow it.
Propagation has rules
BGP does not forward every route to every neighbor. eBGP and iBGP relationships, route-reflector behavior, export policy, and route eligibility all influence where an advertisement can travel.
Withdrawals change reachability
When a route becomes unavailable, BGP can send a withdrawal to remove that advertisement from a peer's usable routing information. The resulting change may trigger a new path selection and further propagation.
Engineering principle
A route known by one router is not necessarily known by every router. A prefix may be absent because it was never advertised, was rejected by policy, was not eligible for propagation, or was withdrawn. Trace the advertisement across each BGP boundary instead of assuming network-wide visibility.
BGP Best-Path Selection: Why One Route Wins
BGP Learning Centre · Foundation 03
Comparing Candidate Paths
A BGP router can learn multiple paths to the same destination prefix from different neighbors. It evaluates eligible routes using path attributes and decision rules to choose a preferred path. Understanding these attributes explains why BGP may select a route that is not physically shortest or that uses a different provider than expected.
From candidate routes to a preferred path
Imagine a router receives three candidate paths for 10.10.10.0/24. The paths may differ in local policy, AS_PATH length, MED, next-hop reachability, and other attributes. The router evaluates eligible candidates according to its implementation and configuration.
Attributes that influence the decision
Weight
On Cisco platforms, Weight is locally significant. A higher value is preferred, but Weight is not propagated to BGP peers and is not a standard BGP path attribute.
Local Preference
LOCAL_PREF communicates an AS's preferred outbound path. A higher value is generally preferred among eligible candidates. It is exchanged within the AS using iBGP and is not normally sent to external peers.
AS_PATH
AS_PATH records the AS numbers traversed by a route. A shorter path is often preferred when earlier decision criteria tie, but policy and higher-priority attributes can outweigh path length.
Origin
ORIGIN indicates how a prefix entered BGP. In the conventional comparison, IGP is preferred over EGP, which is preferred over Incomplete, if the decision reaches this criterion.
MED
MULTI_EXIT_DISC suggests a preferred entry point into an AS. A lower MED is generally preferred when the comparison applies; comparison across different neighboring ASes depends on implementation and configuration.
Next-hop reachability
A candidate must be usable. If the BGP next hop cannot be resolved, the route may be ineligible for selection or installation even when other attributes appear attractive.
Remember the order: attributes do not have a universal impact in isolation. For example, a higher Local Preference generally outweighs a shorter AS_PATH when the applicable decision process evaluates Local Preference first. Always consider route eligibility, configured policy, and platform-specific rules.
Example: why the preferred route can change
In this simplified comparison, assume all three routes are eligible and Local Preference is the first attribute that differs.
| Candidate | Local Preference | AS_PATH length | Illustrative outcome |
|---|---|---|---|
| Path A | 100 | 2 | Lower Local Preference than B and C. |
| Path B | 200 | 4 | Preferred because it has the highest Local Preference, despite its longer AS_PATH. |
| Path C | 150 | 1 | Shorter AS_PATH than B, but lower Local Preference. |
Path B wins under these assumptions. The example demonstrates why the shortest AS_PATH does not automatically win: Local Preference is evaluated earlier in the conventional decision process.
Engineering caveat: the full best-path process includes additional criteria and platform-specific behavior. MED comparison can vary, and route eligibility, policy, and tie-breaks can change the result. This learning stage demonstrates selected attributes rather than reproducing every vendor's complete algorithm.
Next: Compare the paths. Use the interactive best-path stage to change attributes and observe how the preferred candidate changes. Identify which attribute decides the comparison, and confirm the assumptions before applying the result to a production network.
BGP Best-Path Selection: Why One Route Wins
When a router learns multiple eligible paths to the same prefix, BGP evaluates the candidates using path attributes, routing policy and applicable decision rules. The preferred route is not necessarily the shortest physical path or the route with the fewest AS numbers. To explain the outcome, identify the first decisive criterion.
Never diagnose a best-path decision by looking at AS_PATH length alone. Confirm that the candidates are eligible, understand the applicable decision process, and identify the attribute or rule that actually determined the result.
From candidate routes to a selected path
Learn
Receive candidate paths from configured BGP neighbors or other relevant sources of routing information.
Validate
Check route eligibility, import policy, next-hop resolution and other conditions that affect selection.
Compare
Apply the configured decision process to the eligible candidates, comparing attributes in the applicable order.
Select
Choose the preferred eligible path. Installation and forwarding still depend on the routing system and usable next-hop state.
All candidates are assumed eligible and comparable within the same AS. Path B has the highest Local Preference at 200. Local Preference is evaluated before AS_PATH length in the conventional decision process, so Path B can win despite having a longer AS_PATH.
Attributes and conditions to understand
Weight
On Cisco platforms, Weight is locally significant and a higher value is preferred. It is not a standard BGP path attribute advertised to peers.
Local Preference
Used within an AS to express a preferred outbound path. A higher value is generally preferred among eligible candidates.
AS_PATH
Records AS numbers traversed by the route. A shorter path is commonly preferred when earlier decision criteria do not decide the outcome.
MED
Can indicate a preferred entry point into an AS. A lower MED is generally preferred when the comparison applies; comparisons across neighboring ASes depend on implementation and configuration.
Origin and other tie-breaks
ORIGIN and further criteria may decide between otherwise comparable candidates. The exact sequence depends on the platform and configuration.
Next-hop reachability
A route whose next hop cannot be resolved may be ineligible for selection or installation. Attractive attributes do not make an unusable next hop valid.
Test your engineering judgement
Three eligible routes reach the same prefix. Path A has Local Preference 100 and AS_PATH length 2. Path B has Local Preference 200 and AS_PATH length 4. Assume the Local Preference comparison decides before AS_PATH length.
How BGP Selects a Path
Three candidate routes reach the same destination. Compare their attributes, identify the first decisive difference and see why a route can win even when it has a longer AS_PATH.
Select Path A, B or C. The route cards, diagram and evidence panel update together.
Candidate route comparison
Select a candidate to inspect its attributes.
Why Path B wins
Path B has the highest Local Preference at 200. In this example, that difference determines the winner before AS_PATH length is compared.
Assume all three candidate routes are valid and their next hops are reachable.
Decision evidence
Compare the attributes used in this exercise.
| Attribute | A | B | C |
|---|---|---|---|
| Route eligible | Yes | Yes | Yes |
| Local Preference | 100 | 200 | 150 |
| AS_PATH length | 2 | 4 | 1 |
| Origin | IGP | IGP | IGP |
| MED | — | — | — |
| Next hop | Reachable | Reachable | Reachable |
BGP Learning Centre · Stage 03 Complete
What You Have Learned
When several routes lead to the same destination, BGP must determine which path to prefer. The decision depends on the attributes of eligible candidate routes, the router's configuration, and the applicable selection rules.
Three concepts to remember
Compare eligible paths
BGP evaluates candidate routes to a destination prefix.
Route eligibility and earlier decision criteria matter:
a path with a shorter AS_PATH does not
automatically win if another path is preferred by a
higher-priority attribute.
Understand attribute order
In common implementations, attributes such as Cisco
Weight and Local Preference
are evaluated before AS_PATH length. Origin, MED, eBGP/iBGP
status, and later tie-breakers can also matter. Exact
behavior depends on implementation and configuration.
Policy shapes the outcome
Routing policy can change attributes, filter advertisements, and influence which paths are eligible. MED comparisons may depend on configuration, including whether paths from different neighboring autonomous systems are compared.
Engineering principle
Never diagnose a BGP decision by looking at one attribute in isolation. Identify the candidate routes, check their eligibility, compare the decision attributes in the correct order, and inspect the router's actual best-path explanation. The shortest AS_PATH is not necessarily the preferred route.
BGP Troubleshooting: Diagnose Routing Failures
BGP Learning Centre · Foundation 04
A Structured Fault Investigation
When a BGP route disappears or traffic stops flowing, changing configuration at random is rarely the fastest solution. A disciplined investigation follows the evidence from the neighbor session to the received route, policy decisions, best-path selection, next-hop reachability, and the forwarding plane.
A practical troubleshooting sequence
Work from the control plane toward the data plane. Each step answers a different question, helping you isolate the failure domain before making a change.
Session failure
A neighbor stuck outside Established cannot exchange normal BGP routing updates. Check addressing, TCP reachability, remote AS configuration, authentication, timers, and relevant access controls.
Route missing
If the session is established but the prefix is absent, investigate whether the origin router advertises it, whether inbound or outbound policy permits it, and whether it can propagate through the topology.
Wrong path selected
If several routes exist, compare their attributes and policy. A higher Local Preference can outweigh a shorter AS_PATH when it is the first differing criterion in the applicable decision process.
Use the evidence to isolate the fault
| Symptom | Evidence to inspect | Possible cause |
|---|---|---|
| Neighbor is not Established | Neighbor state, TCP connectivity, configuration | Transport reachability, AS mismatch, authentication, or session configuration. |
| Prefix is not received | Originating route, received-route information, UPDATE logs | Missing origination, session problem, or filtering before receipt. |
| Prefix is received but rejected | Import policy and route-policy logs | A prefix list, route map, or another import policy rejects the route. |
| Unexpected best path | Candidate attributes and best-path explanation | Local Preference, Weight, AS_PATH, MED, or another decision criterion. |
| Route exists but traffic fails | Next hop, routing table, FIB, interface and packet path | Unresolved next hop, missing forwarding entry, interface failure, or downstream issue. |
| Traffic fails after a link outage | Neighbor state, withdrawals, alternate paths and convergence | No eligible backup route, failed propagation, or a convergence delay. |
Incident investigation checklist
- Define the symptom. Identify the affected prefix, source, destination, and when the problem began.
- Confirm the topology. Check which links and BGP sessions should provide the route.
- Inspect the received route. Determine whether the route arrived and whether import policy accepted it.
- Compare candidates. Find the selected path and identify the attribute or rule that decided the outcome.
- Trace the next hop. Verify that the next-hop address is reachable and that the route is usable for forwarding.
- Test recovery. After a link or neighbor failure, confirm whether a valid alternative exists and routing state changes as expected.
- Verify the result. Confirm both control-plane state and actual reachability after recovery.
Route state is not the same as traffic success. Historical logs may show a route that is no longer valid or usable. Distinguish event history from current state, and validate the forwarding path separately.
Lab limitation: the incident widget models selected failure and route-state behaviors for learning. Its results illustrate troubleshooting logic; they do not guarantee that every BGP implementation, withdrawal sequence, or convergence event behaves identically.
Next: Investigate the incident. Use the interactive stage to introduce a failure, inspect the affected routers and route state, and determine whether the modeled network retains an alternative path. Restore the link and compare the recovered state with the failure evidence.
An Established BGP Session Does Not Guarantee Route Availability
A BGP neighbor can be healthy while a particular prefix is missing, rejected, or unusable for forwarding. Good troubleshooting separates session health, route processing, and the actual packet-forwarding path.
Never use the BGP neighbor state alone as proof that a destination is reachable. Verify the expected prefix, its route-selection outcome, next-hop resolution, and forwarding state separately.
Three distinct things to verify
Can the peers exchange BGP messages?
Check neighbor state and session details. Established indicates that the BGP session has reached its operational state.
SESSION HEALTHIs the expected prefix available?
Check whether the prefix was received, accepted by policy, considered eligible, and selected as the best path.
ROUTE EVIDENCECan the router actually forward traffic?
Check next-hop resolution, the routing table, forwarding entries, interfaces, and the relevant traffic path.
DATA-PLANE CHECK
Suppose R2 reports its BGP neighbor as Established, but
10.10.10.0/24 is absent from the expected route
information. Investigate advertisement, import policy, propagation
rules and route eligibility before assuming the session is broken.
If the route is present but traffic fails, continue to next-hop and
forwarding checks.
Test your engineering judgement
A BGP neighbor is Established, but users cannot reach 10.10.10.0/24. What is the best next step?
BGP-to-Forwarding Diagnostic Lab
A BGP session is Established, but traffic is not reaching its destination. Follow the route through the control plane and forwarding plane to identify the first failing stage and choose the next troubleshooting step.
Router R1 receives traffic for a destination prefix but cannot forward it successfully.
1. Select an incident scenario
2. Trace the route-processing pipeline
Did R1 learn the prefix from a BGP peer?
Not checkedDid import policy allow the route?
Not checkedIs this route eligible and selected?
Not checkedIs the route installed in the RIB?
Not checkedCan the data plane forward using it?
Not checkedObserved evidence
Simulated command output for the selected incident.
Suggested verification commandsFind the fault
Use the evidence to locate the earliest failed stage, rather than assuming the BGP session itself is the problem.
Inspect the route and forwarding state.
Diagnosis: route is forwarding successfully
HEALTHYKnowledge check
R1 shows the prefix in its BGP table, but the route is absent from the forwarding table. What should you investigate next?
This is a simulated diagnostic exercise, not a live router. Command syntax and the relationship between BGP, the RIB and the FIB vary by platform. A BGP route can be present without being the selected route, installed in the routing table or programmed into forwarding hardware.
BGP CLI Investigation Lab
Investigate a routing incident as a network engineer would: inspect the BGP session, examine the route, check reachability, and compare the evidence before deciding on the fault.
1. Select the incident
R1 is not receiving expected routes from its BGP neighbour. Find the failure point using the available commands.
Evidence collected: 0 of 4 command checks.
2. Run diagnostic commands
Choose a command to inspect the simulated router output. Gather evidence before submitting your diagnosis.
BGP router identifier 10.0.0.1, local AS number 65001 Neighbor V AS State/PfxRcd 10.0.0.2 4 65001 12 10.0.0.3 4 65002 4
3. Evidence collected
Each command can reveal a different part of the control-plane or forwarding pipeline.
Run the diagnostic commands above to begin the investigation.
4. Investigation checklist
Submit your diagnosis
Engineering principle
Do not assume that an established BGP session proves a prefix is accepted, selected as best, resolvable, or installed in the forwarding table.
Trace the route through each stage and use the command output to support your conclusion.
Training simulation only. Command syntax and output vary by network operating system and software version. The scenarios model common diagnostic patterns rather than a live router. In production, confirm the relevant vendor documentation and use platform-appropriate commands before making changes.
BGP Fault Investigation: Follow the Evidence
Effective BGP troubleshooting is a process of narrowing down where expected routing behaviour diverges from observed behaviour. Start with the symptom, gather evidence at each stage, and change the configuration only when you have a defensible hypothesis.
An Established session proves that the peers have reached the Established state. It does not prove that a particular prefix was received, accepted by policy, selected as best, installed in the routing table or programmed into the forwarding plane.
A repeatable troubleshooting workflow
Define the symptom
Identify the missing prefix, failed destination, affected router and expected outcome. Establish when the problem began.
Collect evidence
Check session state, received routes, policy counters, best-path output, next-hop reachability and relevant logs.
Isolate the layer
Determine whether the issue concerns connectivity, session establishment, route exchange, path selection or forwarding.
Verify the outcome
Confirm the intended route state, next-hop resolution and end-to-end reachability after the corrective action.
10.10.10.0/24 in its routing information.
The team reports that the upstream BGP session is Established.
Check 1 · Session state
Confirm the relevant peer is Established, review uptime, and check whether resets or notification events coincide with the incident.
Check 2 · Prefix reception
Determine whether 10.10.10.0/24 is actually
received from the expected neighbor. If not, investigate
origination, advertisement and upstream policy.
Check 3 · Import policy
If the route arrives, inspect prefix lists, route maps, import policies and filtering counters to find whether the candidate is rejected or modified.
Check 4 · Selection and forwarding
If accepted, inspect best-path output, next-hop reachability, the routing table and forwarding state. A route may be received without becoming the selected usable path.
Trace the route through the evidence chain
Is the expected peer Established, and is the session stable? If not, investigate transport reachability, TCP/179, configuration and BGP error evidence.
Does the expected prefix arrive from the intended neighbor? If it is absent, trace the advertisement back toward its origin.
Check import policy, route validity, next-hop resolution and other eligibility conditions before blaming the best-path algorithm.
Confirm the selected path, routing-table installation, forwarding entry and destination reachability. These are related but distinct checks.
Investigation readiness checklist
Use this checklist before making a change. Tick each item once you have gathered or verified the corresponding evidence.
BGP Incident Investigation
Inject a link failure, inspect the affected routers, and investigate the assumed impact on route availability. Follow the evidence before deciding what to repair.
1. Inspect the BGP topology
Select any router or session. The topology uses the six-router Learning Centre design: R1, RR1, R4 and R5 in AS65001, R2 in AS65002, and R3 in AS65003.
2. Inject an incident
Choose a BGP session and simulate a link or session failure. You can also select a connection directly in the diagram.
3. Inspect a router
Select a router in the diagram or use the selector to inspect its role and current simulated connectivity.
AS65001. Connects to the internal route-reflector domain and external peer R2.
4. Trace the illustrative route
The model treats R1 as the route source for this exercise. Green hops indicate connectivity from R1 across the displayed topology; red hops indicate that the simulated path is interrupted. Actual BGP route selection depends on received routes, policy, attributes and available alternatives.
5. Diagnose the incident
Inject a failure first. Then choose the diagnosis that best matches the selected connection. Use the topology and status indicators as your evidence.
Investigation event log
1 eventCan You Diagnose the BGP Outcome?
A network engineer must connect control-plane evidence to the routing outcome. Use this short scenario to test your understanding of session state, best-path selection and next-hop reachability before moving on to the interactive BGP simulator.
Read the scenario, choose one answer for each question, and check your responses. Each question provides an explanation, so the exercise teaches the reasoning behind the answer rather than simply marking it right or wrong.
What does an Established BGP session prove?
R2 has received the prefix, but R4 does not have it. What is a useful next step?
A route appears in BGP, but traffic still fails. Which investigation is most appropriate?
BGP Learning Centre · Stage 04 Complete
What You Have Learned
BGP troubleshooting is most effective when you investigate the evidence in a structured order. Start with the neighbor session, trace the route through the control plane, inspect policy and path selection, and then verify next-hop reachability and forwarding.
Three concepts to remember
Start with the session
Check neighbor state, configured peer addresses, local and remote ASNs, and underlying IP reachability. A session that is not established cannot exchange normal BGP route updates. A session that is established still needs route-level checks.
Trace the missing or unexpected route
Check whether the prefix is present, received from a neighbor, accepted by policy, and eligible for selection. Compare candidate attributes and inspect route-reflector or other propagation rules when a route fails to reach its intended destination.
Verify the forwarding path
Confirm that the selected route has a resolvable next hop and that the relevant routing and forwarding entries are usable. Then investigate the data path, interface state, filtering, and return path if traffic still fails.
Engineering principle
Diagnose the first point where expected behavior diverges from observed behavior. Do not assume that a failed ping means BGP is broken, or that an established session proves the route is usable. Follow the evidence from session state through route processing to actual packet forwarding.
The BGP Engineer’s Field Guide
Understanding BGP is more than memorising attributes and commands. Engineers need a repeatable way to collect evidence, explain routing decisions, document incidents and verify that a change has restored the intended behaviour. Use these field notes as a compact reference when working through real or simulated routing scenarios.
Record what the router actually shows before deciding what should change. Separate the control plane from the forwarding plane, and distinguish a confirmed finding from a working hypothesis.
Four habits of effective BGP troubleshooting
Start with the exact prefix
Write down the network, expected path, affected router and observed symptom. Avoid vague descriptions such as “BGP is broken” when the fault may affect only one route.
Trace each route stage
Establish whether the route was received, accepted by policy, considered eligible, selected as best and installed for use. These are separate questions.
Change one thing at a time
Form a testable hypothesis, make an approved targeted change, and compare the result with the original evidence. Multiple simultaneous changes make cause and effect harder to establish.
Verify the forwarding result
Do not stop at a successful BGP command or a visible route. Check next-hop reachability, routing-table installation, forwarding state and appropriate end-to-end tests.
Use this structure to document a lab result or prepare a concise operational handover. Replace the prompts with verified facts.
Before you close the investigation
Run through this final review. Your selections update the progress indicator locally in this widget.
From BGP Fundamentals to Engineering Practice
You have explored four essential stages of BGP operation: understanding network topology, tracing route propagation, analysing best-path selection, and investigating routing failures. Together, these stages provide a foundation for understanding how BGP behaves in real networks.
Connect the concepts
Understand autonomous systems and BGP neighbours, follow route advertisements, compare path attributes, and examine how routing information influences forwarding decisions.
Find the cause, not just the symptom
A route may be received but not selected, selected but not advertised, or withdrawn after a failure. Follow the evidence to identify where actual behaviour differs from expectations.
Do not stop at asking which route won. Determine why it won, where the route came from, which policies influenced it, and how a topology change or failed BGP session affects the available paths.
Now put your knowledge into practice
Return to the interactive simulator, explore routing behaviour, and practise explaining the evidence behind each BGP decision.
Where to Go Next
Continue your learning
Recommended Reading
Explore related Network Insight articles covering BGP fundamentals, routing architecture, path selection, security, FlowSpec and enterprise WAN design.