topology | ||
util | ||
.gitignore | ||
attach.py | ||
CONTRIBUTING.md | ||
LICENSE | ||
README.md | ||
route-0.py |
Route 0
Route 0 is a suite for learning about and experimenting with routing protocols. It uses the Free Range Routing (FRR) protocol implementations running on top of a network setup locally using Mininet.
Introduction
Motivation
Mininet is a great tool for teaching, learning, and experimenting with networking. However, there was no coherent framework or easy to examples to follow which would let one use Mininet to setup a network running a bunch of routing protocols. The FRR project actually uses Mininet for running topology tests, but that makes them difficult to learn from and experiment with. As somebody looking for resources to learn about configuring networks to play with on my own computer that seemed like a big gap.
Purpose
The primary purpose of Route 0 is to provide a framework for learning how routing works all the way from setting up IP addresses on individual interfaces up to setting up BGP peering sessions between multiple autonomous systems and setting up VPN tunnels. Therefore, the primary audience are people new to networking. However, even if you already know some routing basics you might still find some of the examples valuable. The repository is structured such that you can start from any point you like.
A secondary purpose is to provide an experimental testbed in which a network running a whole stack of routing protocols can be quickly designed, provisioned, and brought up on a single computer.
Getting Started
Platform
For the best experience it is recommended to run Route 0 experiments using the Virtual Machine (VM) image developed specifically for this project.
TODO: INSTRUCTIONS FOR VM IMAGE
Note that the VM does not come with the route-0
repository. This is because
the repository will be updated much more frequently than the VM image. You
will still need to clone route-0
into an appropriate directory on the VM. To
do so run
git clone https://github.com/Wojtek242/route-0.git
If you would prefer to set up your own environment, you can follow these instructions. They describe the steps needed to produce the exact same VM image available above.
Note that both Mininet and FRR are developed primarily for Linux so if you have a different operating system you will have to use some form of virtualisation. With some effort (and limitations) you might be able to get things running on other Unix-like systems, but that is undocumented.
Running an experiment
If you just want to get started, choose a topology from the topology
directory, and a scenario from the scenario
directory within. Note that all
topologies support plain
and basic
in addition the explicit defined
scenarios. The meaning of these special scenarios is explained later on in
this README
in the section on scenarios.
Once you have chosen <topology_name>
and <scenario_name>
you can run an
experiment with the following command.
sudo python route-0.py --topology <topology_name> --scenario <scenario_name>
Connecting to an FRR daemon
To connect to an FRR daamon, you can either run the following command inside the Mininet CLI
<node_name> telnet localhost <daemon_name>
You can also connect to an FRR daemon from a different terminal than the one in which the Mininet CLI is running. To do this run
sudo python attach.py --node <node_name> --daemon <daemon_name>
The password for all daemons is route0
.
Lessons
TODO: WRITE UP LESSONS
Mininet Concepts
This section will introduce some basic Mininet concepts that are in particular useful for Route 0. For more information, please refer to the Mininet documentation.
Mininet is a framework for creating virtual networks running real kernel, switch, and application code. In Route 0 it is used to provide the virtualisation necessary to run multiple routing nodes on a single computer. Mininet handles the topology setup before dropping the user in its own special CLI.
The CLI is self-documented and help can be accessed by running help
. To
investigate the current topology, you can run net
. To visualise the output
of this command, you can copy and paste it into this web
tool.
A particularly useful feature of the CLI is the ability to run shell commands on any of the nodes in the network. To do this, simply run
<node_name> <shell_command>
such as R1 ifconfig
. This is particularly useful in Route 0 for commands
like ifconfig
or ip route
. Additionally, it is possible to use this
feature to send ping between nodes, for example, R1 ping 10.0.0.1
. Normally,
in Mininet the destination can also be specified using its name. It is
possible to do so in Route 0, but this is often ambiguous as routers will have
multiple IP addresses associated with their interfaces.
It is also possible to launch a shell or run a command in a Mininet node from a
different terminal than the one in which the Mininet CLI is being run. A
convenience script has been provided for this purpose, attach.py
. To launch
a shell in a particular node run
sudo python attach.py --node <node_name>
You can also directly specify the daemon to connect to with --daemon
or a
shell command to run with --cmd
.
The password for all daemons is route0
.
FRR Concepts
This section will introduce some basic FRR concepts that are in particular useful to understand for Route 0. For more information, please refer to the FRR documentation.
FRR is a set of routing protocols with each running in its own daemon. In
addition, there is a central IP routing manager, zebra
, which must be run
before any other routing daemon is started. All other routing protocols talk
to zebra
which in turn will talk to the operating system kernel to install
routes as appropriate.
FRR routing protocols are configured using configuration files. The details of how to write these configurations are on the FRR documentation website. It is also possible to connect to running instances of the protocols. See the Mininet and Getting Started sections on how this can be done.
Structure
There are three key concepts in the Route 0 framework: topology, scenario, and experiment.
Topology
A topology defines the nodes and links that form the network. Additionally it
also determines the default IP address assignments and any static routes which
are initialised using the zebra
and staticd
daemons.
Each topology has its own directory in the topology
directory. Every
topology directory must contain a topo.py
file which defines a NetTopo
class. The topology itself is defined in the constructor of this class using
the Mininet API.
A README.md
should be provided with each topology that has a schematic
diagram of the topology and lists all the default IP address assignments. It
is assumed that hosts have a default route setup to the router they connect to
and that routers do not have default routes.
Scenario
A scenario is a particular configuration of FRR daemons on the provided topology. While the topology defines which nodes and links form the network, the scenario determines which daemons get started on which nodes and their configuration.
There are two special scenarios: plain
and basic
. The plain
scenario
starts the network without any daemons so only the Mininet topology is set up,
but no IP addresses or default routes are created. The basic
scenario
additionally starts up zebra
and staticd
to configure addresses and default
routes.
Scenarios are defined for a particular topology and thus they can be found in
the scenario
directory within the topology directories. There is no python
code associated with a scenario, only FRR configuration files. Each scenario
(excluding the special ones) should have a directory in the scenario
directory. Within the particular scenario directory, each daemon that is to be
run must have a its own directory. The configuration files should be created
in the appropriate daemon directory with the name <node_name>.conf
.
The zebra
and staticd
daemons are special and have their own directories
directly in the topology directory. If a scenario has its own zebra
and/or
staticd
directory, these will be used preferentially, but otherwise the
topology's ones will be used. Note that if no zebra
and/or staticd
daemon
is to be run then the scenario must have empty zebra
and/or staticd
directories within its scenario directory.
Experiment
An experiment is simply a particular topology and scenario combination. Technically this is redundant since scenarios are strictly associated with only one topology, but using different terminology avoids confusion.
Contributing
For information on how to contribute see CONTRIBUTING.
Name
I am terrible at coming up with names so I'll at least explain myself. The word "Route" was chosen due to its dual meaning. A route is naturally a central concept in networking, but it in every day English it simply means a path, a track, a road. This repository is a tutorial, a road to learning about routing protocols, hence a "Route". The number 0 is used to indicate that this is the first route one would take in their networking education.