Network Insight · Interactive Learning Centre
BGP Learning Centre: Explore. Trace. Diagnose.
Learn Border Gateway Protocol through practical network engineering. Explore autonomous systems, trace route propagation, investigate best-path decisions and diagnose routing failures using an interactive BGP simulator. Move beyond theory and see how BGP behaves.
Explore BGP Through Interactive Engineering Labs
Border Gateway Protocol (BGP) is fundamental to how networks exchange routing information across the internet. Understanding it requires more than memorising 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 interactive learning environment takes you through four practical stages, from BGP architecture and route propagation to best-path selection and incident investigation. Each stage combines engineering explanations with an interactive model so you can explore routing behaviour and understand the reasoning behind the outcome.
You will examine autonomous system relationships, follow route advertisements, compare competing paths, and investigate failures. The aim is to develop the analytical approach needed to troubleshoot BGP in real network environments.
Your learning journey: Understand the topology → Trace the route → 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 Learning Centre · Foundation 01
BGP Architecture and Topology
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.
Interactive BGP engineering workbench · Stage 1
Explore a multi-AS BGP topology
Select a router to inspect its role, autonomous system and BGP neighbours. Switch to route walkthrough to follow an example prefix across the network.
Network topology · select a router
Topology note: the links show conceptual BGP peer relationships, not a complete production configuration. Route propagation between iBGP speakers requires a valid design, such as a full mesh or route reflectors. A physical connection alone does not establish a BGP session.
R1 — Border router
R1 sits at the edge of AS65001 and represents a router that can exchange routes with other ASes or internal BGP peers.
Inspect peer state, import/export policy and route eligibility when validating BGP route exchange.
A prefix is originated
AS65001 originates reachability for 10.10.10.0/24. The prefix must be available to BGP through configuration and routing state before it can be advertised.
BGP advertises reachability information; it does not carry the user packets themselves.
Ready to investigate BGP yourself?
Explore BGP sessions, routing policies, path attributes and best-path decisions in the full interactive simulator.
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 the routes it receives, applies routing policy, and decides which information can be selected and advertised to other peers.
Follow a route advertisement
Consider the example prefix 10.10.10.0/24. The following stages describe the general lifecycle of a BGP route; the exact outcome depends on the topology, session state, policy, and routing 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
The NEXT_HOP attribute identifies the next-hop address used to reach the advertised destination. The receiving router must have a usable route to that next hop for forwarding to work.
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's loop-prevention rules.
Key distinction: physical connectivity is not the same as route propagation. Two routers can be connected but still fail to exchange a particular prefix because a BGP session is down, a policy rejects the route, the route is ineligible for advertisement, or an iBGP design constraint prevents further propagation.
What to check when a route is missing
| Check | Question to answer | Possible finding |
|---|---|---|
| Neighbor state | Is the BGP session established? | The peers cannot exchange routes while the session is down. |
| Received route | Did the router receive the prefix? | The advertisement may never have arrived or may have been filtered. |
| Import policy | Was the route accepted? | A prefix list, route map, or other policy may reject or alter it. |
| Best-path selection | Was the route selected? | Another candidate may be preferred, although a non-best route may still be advertised in some circumstances. |
| Next-hop reachability | Can the router resolve the next hop? | The route may be unusable for forwarding if the next hop cannot be resolved. |
| Export and propagation | Can the route be advertised to the next peer? | Export policy or BGP propagation rules may prevent advertisement. |
Withdrawals matter too: when a route becomes unavailable or is no longer advertised, BGP can send a withdrawal to remove that path from a peer's routing information. The network may then select an alternative path 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 teaching model represents route updates, and identify where topology or policy can change the outcome. The widget is a simplified learning model, not a complete implementation of every BGP protocol rule.
How BGP Routes Propagate
Follow a network prefix from its origin, across BGP peers, and into a remote autonomous system. Advance through six steps to explore the connections, AS_PATH changes and propagation rules.
R1 originates the prefix
R1 originates 10.10.10.0/24 into BGP within AS 65001.
Route attributes
- Prefix
- 10.10.10.0/24
- Current router
- R1
- AS_PATH
- 65001
- Session
- Local origination
- Next hop
- Local
BGP event log
This is an educational walkthrough, not a live router simulation. Route acceptance, export policy, next-hop reachability, route reflection and best-path selection can change actual behaviour. The displayed next-hop values are illustrative.
BGP Learning Centre · Foundation 03
How BGP Selects a Path
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 the 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 a locally significant attribute. A higher value is preferred, but Weight is not propagated to BGP peers and is not a standard transitive BGP path attribute.
Local Preference
LOCAL_PREF communicates an AS's preferred outbound path. Among otherwise eligible candidates, a higher value is generally preferred. It is exchanged within the AS using iBGP and is not normally sent to external peers.
AS_PATH
AS_PATH records 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; whether MED is compared 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: an attribute does not have a universal impact in isolation. For example, a higher Local Preference generally outweighs a shorter AS_PATH when the router's decision process compares those attributes in that order. Always consider route eligibility, configured policy, and the platform's decision rules.
Example: why the preferred route can change
| Candidate | Local Preference | AS_PATH length | Illustrative outcome |
|---|---|---|---|
| Path A | 100 | 2 | Lower policy preference in this example. |
| Path B | 200 | 4 | Preferred if both paths are eligible and Local Preference is the first differing criterion in the applicable decision process. |
| Path C | 150 | 1 | Better than A by Local Preference, but below B on that criterion. |
In this illustrative comparison, Path B wins because its Local Preference is highest, even though it has a longer AS_PATH. The example assumes the routes are eligible and that no earlier criterion or configured policy changes the outcome.
Engineering caveat: the full BGP best-path process includes additional criteria and platform-specific behavior, such as route originator details, route age, peer type, router ID, and implementation-specific tie-breaks. MED comparison behavior can also vary. The interactive stage is designed to teach selected attributes, not to reproduce 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. Focus on which attribute decides the comparison, and confirm the assumptions before applying the result to a production network.
BGP Best-Path Selection
Three peers advertise the same prefix. Explore their attributes, change the values, and recalculate the preferred route using this simplified Cisco-style decision model.
Route attribute editor
Select a route, change its attributes, and recalculate the outcome.
AS_PATH example: 65030 65040. Use valid AS numbers from 1 to 4294967295. An empty AS_PATH is allowed for a locally originated route.
Decision process
The attributes are evaluated in sequence. The first criterion that distinguishes the remaining candidates decides the result.
- Highest Weight
- Highest Local Preference
- Shortest AS_PATH
- Preferred Origin type
- Lowest comparable MED
- Additional tie-breaks
Path B has the highest Local Preference among these candidates.
What this investigation teaches
A Cisco-specific attribute local to the router. It is not advertised to BGP peers.
Communicates the preferred exit path within an AS. A higher value is preferred.
A shorter AS_PATH is preferred when earlier criteria tie. Lower MED is preferred when the relevant routes are compared.
Educational model only. It assumes all three routes are valid and eligible and omits several real-router decision steps. MED comparison behaviour can depend on configuration and vendor. When the model cannot distinguish remaining paths, it reports a tie instead of pretending the alphabetically first route is necessarily the BGP winner.
BGP Learning Centre · Foundation 04
Diagnosing BGP Failures
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 outbound or inbound policy permits it, and whether the route can propagate through the topology.
Wrong path selected
If several routes exist, compare their attributes and policy. A higher Local Preference, for example, 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, Adj-RIB-In where available, UPDATE logs | Missing origination, session problem, or filtering before receipt. |
| Prefix is received but rejected | Import policy and route-policy counters or logs | 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, route 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 time 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. If a link or neighbor fails, confirm that a valid alternative exists and that the routing state changes as expected.
- Verify the result. Restore the intended topology and confirm both control-plane state and actual reachability.
Route state is not the same as traffic success. A route may remain visible in historical logs after a failure, while its current validity or forwarding status has changed. Distinguish event history from current state, and validate the forwarding path separately.
Lab limitation: the incident widget is an educational model of selected failure and route-state behaviors. 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.
BGP Incident Investigation
Inject a link failure, inspect the affected routers, and investigate how a broken BGP path changes route availability across an autonomous-system chain.
1. Inspect the topology
Select a router to inspect it, or select a link to prepare a failure. Green links are operational; a red dashed link represents the injected fault.
2. Inject a link failure
Choose a link, fail it, then inspect which routers remain connected to the modeled route origin.
3. Router inspection
Select a router in the diagram or use this selector.
4. Trace the modeled route
Green means the prefix is present in this simplified model; red means the modeled path is interrupted before that router.
5. Engineer challenge
A link has failed in this linear training topology. What should you investigate first?
Incident event log
1 eventFrom 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.