Course Project · CSE 3150

How does the
internet know
where to send your data?

This project simulates the real system every internet provider uses to find the best path for data — called BGP. Think of it like a massive, automated GPS for the entire internet.

Watch the explainer ↓ How it works ▶ Run Simulation
3Phases
6Files
C++23Language
Plain English

The internet is just a bunch of neighbours sharing directions.

Every company, university, or internet provider that owns a chunk of the internet is called an Autonomous System (AS)A company or organization that controls a block of IP addresses and has its own routing policy. There are ~70,000 ASes on the internet today.. They're like towns on a map, each with their own roads.

When you send a message, it doesn't magically jump from you to the destination. It hops through dozens of these "towns," and each one has to decide: which way should I forward this?

BGPBorder Gateway Protocol — the routing protocol that glues the internet together. It's been running since 1994 and handles over 900,000 routes today. is the system all these towns use to talk to each other about the best routes. This simulator recreates that exact system from scratch, using real internet data.

Built on real data from CAIDA — the organization that maps the actual internet's structure. These are real internet relationships, not made up.

🌐

Autonomous Systems

Tap to reveal the analogy →

= Towns on a map

Each AS is like a city with its own roads. Big cities (Tier-1s) connect to everything. Small ones sit at the edges. Your data travels city to city.

📢

BGP Announcements

Tap to reveal the analogy →

= Shouting directions

A town broadcasts: "Hey! I own these addresses. Here's how to reach me!" Every neighbour hears it and updates their map.

🤝

Relationships

Tap to reveal the analogy →

= Business deals

Some towns pay others for access (providers). Some swap routes for free (peers). BGP always picks the route that makes the most business sense.

Video Explainer

BGP explained like you're
sending a pizza order across the world.

No computer science background needed. Press play and we'll walk you through it.

1 / 7
How it works

Routes spread in three rounds.

Like gossip spreading through a school — first up to teachers, then between teachers, then back down to students — BGP follows a strict three-phase order.

01

Routes travel upward — from small to big

The smallest providers tell their upstream neighbours what they own. Think of it like students passing notes up to the teacher — rank by rank, until the headmaster (core) knows everything.

Fun fact: A single leaf AS might have routes that end up influencing routing decisions on the other side of the planet within seconds.
Phase UP ↑
02

Routes spread sideways — between equals

Providers at the same level swap route tables all at once — like everyone in a room turning to their neighbour simultaneously. This "atomic" swap stops routes from sliding more than one hop sideways.

Fun fact: This one rule — "all sends before any processing" — is what makes valley-free routing actually work in the real internet.
Phase PEER ↔
03

Routes travel downward — back to everyone

The core now has a complete map and pushes it back down — like a teacher returning corrected homework to every student. By the end, every AS on earth knows the best path to every address.

Fun fact: The full BGP table today contains over 900,000 routes. Our simulator handles all of them.
Phase DOWN ↓
The Code

Six files. One complete internet simulator.

Each file has one clear job. Clean separation — that's good engineering.

.H
Announcement.h
Defines what a single route advertisement looks like — where it's going, how it got there, and whether it might be a fake hijack attempt.
.H
AS.h
Defines what an internet provider looks like — its neighbours, its best known routes, and incoming messages waiting to be processed.
.CPP
graph.cpp
Reads real CAIDA internet data and builds the full map of who is connected to who, and what kind of relationship they have.
.CPP
route_flow.cpp
The brain of the project. Runs the three-phase propagation, applies route selection rules, and ensures no loops or bad routes sneak through.
.CPP
output.cpp
Handles all file reading and writing — loading input data, converting address strings to fast integers, and printing the final routing table.
.CPP
main.cpp
The starting point. Ties everything together — reads files, checks for broken data, determines propagation order, then runs the simulation.
Smart Choices

Why we built it this way.

Every engineering decision has a reason. Here's the thinking behind the key ones — in plain English.

01
Numbers instead of address strings click to explore ↓
Addresses like "8.8.8.0/24" get converted to simple integers at the start. Looking up a number is much faster than a string.
How much faster? Integer hash lookups are O(1) with tiny constants. At a million route lookups per second, string hashing would add ~40% overhead. That's the difference between a 2-minute simulation and a 3-minute one on real CAIDA data.
02
Rank-based order, not random firing click to explore ↓
Instead of sending messages randomly, we pre-sort every provider into layers. Propagation runs in a clean, predictable order.
Why does order matter? If a higher-rank AS processes routes before receiving all customer announcements, it might pick a suboptimal route and never correct it. Rank-based processing guarantees every AS sees all possible routes before deciding.
03
Loop detection built right in click to explore ↓
Before any provider accepts a route, it checks: "am I already in this path?" If yes, it drops it silently.
What happens without this? In 2008, Pakistan Telecom accidentally hijacked YouTube's routes. Without loop detection, BGP announcements can bounce endlessly, making huge chunks of the internet unreachable. This single check prevents that class of bug.
04
Relationships from the receiver's view click to explore ↓
The relationship field is recorded from whoever received the route — customer beats peer beats provider.
Real ISP logic: An ISP always prefers routes from customers (they pay!) over peers (neutral) over providers (we pay them). This single preference field drives the entire economic structure of how the internet routes traffic globally.
05
Optional security filtering (ROV) click to explore ↓
Security-conscious providers reject any route flagged as potentially fake — a real feature called Route Origin Validation.
BGP hijacks are real: In 2022, a misconfigured router briefly rerouted traffic meant for major financial institutions. ROV filtering, if widely deployed, would have caught it in milliseconds. Our simulator models exactly this protection.
06
Check for broken data before starting click to explore ↓
Before the simulation runs, a DFS sweep checks whether provider relationships form impossible loops.
Why DFS specifically? Depth-First Search can detect back edges — exactly what a provider cycle looks like in graph terms. It runs in O(V+E) time, so even on graphs with 70,000+ ASes it finishes in milliseconds before the main simulation starts.
Live Demo

Run the simulator right here.

Upload your files, enter a target ASN, and watch the BGP simulation run entirely client-side via WebAssembly — no server, no uploads, no waiting.

Loading WebAssembly engine…
WebAssembly engine ready
Simulation Inputs
🗺️
AS Graph File
No file selected
Format: asn|asn|rel per line
e.g. 123|456|-1
🛡️
ROV ASNs File
Optional
One ASN per line.
Leave empty to skip ROV.
📡
Announcements CSV
No file selected
Header: seed_asn,prefix,rov_invalid
Initializing…
Results
Prefixes: 0
ASN: —
ASNPrefixAS Path

Download Source Files

Get the full C++ source code for the BGP Simulator. Click any file to download individually, or grab them all at once.

Tweaks
Animation Speed
Node Count
Active Phase