Part 1 - Getting Started (10.05. - 17.05.2024)
Finally! You have heard the first lectures, registered for a group, and received your access credentials. Let’s get started!
This week, you will obtain access to all the different kinds of virtualized devices and familiarize yourself with the most basic CLI features. Internally, the Mini-Internet is based on a large number of interconnected Docker containers. We encourage you to learn about Docker - it is awesome. However, it is fully outside the scope of this course - everything Docker-related has been preconfigured by us. Your virtual network already runs and desperately awaits you to configure it. For your convenience, we have set up a proxy container for each group from where you can access your routers, switches, and hosts, as well as the measurement service.
In the following section, we show you how you can access your main docker container and, from there, your FRRouting routers, Open vSwitches, and hosts so that you can configure them.
Accessing Your Docker Container
Connecting to Your Container with SSH
To access your container, you will use SSH. SSH is a UNIX-based command interface and protocol for securely accessing a remote computer. System administrators widely use it to control network devices and servers remotely. An SSH client is available by default on any Linux and MAC installation through the Terminal application. For Windows users, a good and free SSH client is PuTTY; alternatively, you can use Windows Subsystem for Linux. You received the required password via e-mail. However, before we start our SSH connection, we need to connect to the TUD network.
Warning
Do not confuse SSH with SSL.
Connecting to TUD Network and Mini-Internet Servers
The TUD-wide firewall protects the Mini-Internet servers so you won’t have direct access to your container. You first need to establish a connection via either VPN or SSH JumpHost.
Cave
You can use one method you prefer. There is no need to use both a VPN and the SSH JumpHost. If you cannot connect to your container with either method, please report it immediately in the Matrix-Channel.
Note
If you want to simplify the access to your container (optional), please use SSH key authentication. You can find the instructions below. Do not change your password or the key already available on the container.
Connecting with SSH & TUD-VPN
Using a VPN connection, you’ll be virtually part of the TUD network. Follow the instructions on TUD’s website to establish a VPN connection and use the following command to connect yourself to your container afterwards:
X = 2000 + group_number. For instance, if you are in group 7, use the following
command:
Note
You will find the required password for internet.netd.cs.tu-dresden.de in OPAL.
Connecting with SSH & SSH JumpHost
SSH allows to connect to a remote server via an intermediate JumpHost as explained in the ssh manpage:
-J destination
Connect to the target host by first making a ssh connection to the jump host described by destination
and then establishing a TCP forwarding to the ultimate destination from there. Multiple jump hops
may be specified separated by comma characters. This is a shortcut to specify a ProxyJump
configuration directive. Note that configuration directives supplied on the command-line generally
apply to the destination host and not any specified jump hosts.
Use ~/.ssh/config to specify the configuration for jump hosts.
Using a dedicated login server you’ll first connect via ssh to the login server and then (automagically) to your container.
Use the following command:
where X = 2000 + group_number.
Please note that you need to provide the -J option every time you use an ssh command on your local machine connecting to your container, for instance, to save your backups.
You can omit the -J option when you configure the ProxyJump option in your ~/.ssh/config file as below:
Note
You will find the required password for internet.netd.cs.tu-dresden.de in OPAL.
SSH Key Authentication (optional, but recommended)
If you want to simplify access to your container, you can use SSH key authentication.
Ask us or Google it if you want to know more about this, but do not change your password or the key already available on the container. Follow the instructions below to add your own key to the container.
In general, the setup consists of two steps:
First, you need an SSH key pair. If you already have one, you can skip this step. Otherwise, you can generate it with the following command:
Follow the instructions from the command to create a new key pair in the default location ~/.ssh/id_rsa (private key) and ~/.ssh/id_rsa.pub (public key).
Second, you need to copy the public key to the proxy. You can do this with the following command:
Now you can connect to the proxy without entering a password.
If your key is not in the default location, you must specify the key with the -i option when using the ssh command, or add an entry to your SSH config file (see below).
SSH config (optional, but recommended)
To avoid typing the host, port number and username whenever you want to connect to your proxy, you can add an entry to your SSH config file.
This file is located at ~/.ssh/config, and you can create it if it does not exist. Add the following entry to the file:
Replace X with your group number.
If you have multiple SSH keys or an SSH key that is not in the default location,
You can add IdentityFile /path/to/your/key to the entry.
You are also free to choose a different name than commnet for the Host entry.
Note
The above example configuration assumes you use the TUD-VPN. Use your favorite search engine to find out how to adapt the configuration for using the SSH JumpHost.
After adding the configuration, you can connect to your proxy with the following command, using whatever name you chose for the Host entry:
That’s it! Combined with SSH key authentication, you can now easily connect to your proxy.
Additionally, IDEs like VSCode or PyCharm parse your SSH config file and allow you to connect to your proxy directly from the IDE when they find an entry.
Accessing Your Routers, Switches and Hosts
The following paragraphs describe how you can access your routers, switches, and hosts from your container. At this point, you are obviously just starting to find out how generously we have provided you with devices and how we have named them all, but we will explore the topology in depth during the next few weeks.
Access to Routers
When you are in your proxy, use the script goto.sh to connect to a router, a switch or a host.
For example, with either of the following commands, you will access the router CAIR:
Now you are directly in the CLI of the router CAIR.
We will describe the FRRouting CLI in more detail during the upcoming weeks.
For now, just return to the container CLI by entering exit.
Warning
On some routers, you can access the underlying Linux container. This is not required for any task. In particular, do not use any ip commands on the router container. These changes are not detected by FRRouting, and any mismatch between the container and FRRouting config leads to errors that are very difficult to debug and fix.
Access to Switches
Similarly, you can access a switch with the goto.sh script.
Simply use L2N (for the northern L2 network) or L2S (for the southern L2 network) as the first argument for the script, and the switch name as the second argument.
An example to access switch S2 in the northern L2 network is:
Unlike FRRouting, there is no CLI for Open vSwitch.
Hence, after you have run the above command, you are not directly on (an interface of) the switch, but on the Linux device that contains and simulates the switch.
In other words, what has changed is that you are now in a different terminal from which you can externally configure the simulated switch by running OpenvSwitch commands.
This is what we are going to do next week.
For now, just return to the container CLI by entering exit.
Access to Hosts
From your proxy, you can also go to a host.
For example, if you want to go to the host connected to NAIR, just use the following command:
If you want to access the A_AU host connected to S1 in the northern L2 network, you can use the following command:
Important
Whether on a router, switch, or host, you can always use exit to get back to your main container, where you can use the goto.sh script to access a different device or host.
For debugging it can also help to run multiple ssh sessions at the same time.
Simply open a new terminal window and connect to your main container once more.
Finally, note that the goto.sh script supports autocompletion.
Press the Tab key to autocomplete what you started to write or get a list of possible options.
Backup Your Work
To save the configuration of all your routers and switches, we provide you with a script called save_configs.sh.
To be able to return to the fully working initial state later, perform the backup right now!
Once executed, you will receive two equal folders following the naming convention: configs_[date]_[time].
One folder is already zipped for a simpler download.
We advise you to run this script regularly and to save the generated folders on your local machine to have a backup of your work.
To download the zip file generated by the ./save_configs.sh script, you can use scp:
X is your group number and you have to adapt DATE and TIME to match the filename of your zip file.
Note the dot at the end of the command and the capitalized P.
Warning
Occasionally, we have observed issues with the scp command.
Check that you have not forgotten the `-O’ flag.
If the command still does not work for you, use the following workarounds:
- UNIX: download the archive using
sshonly. The./save_configs.shscript will provide you with the exact command to run. When using this workaround, make sure to usesshfrom your own computer and not from the proxy! If you ran it from the proxy by accident, you must runsave_configs.shagain before re-trying from your own computer. - Windows: use WinSCP to download the files. Connect to
internet.netd.cs.tu-dresden.deusing theSCPprotocol, using your group port, usernameroot, and your group password.
FRRouting CLI Basics
After you have completed the backup, we can start playing around a little, and we will now briefly explore how to configure an FRR router. This is a very short FRR introduction. When we get to layer 3 configurations, you will have to learn a lot more by consulting the official documentation.
The following paragraphs describe the auto-completion features of the CLI, how to test connectivity, how to switch to configuration mode, and how to remove a command/reverse your configuration actions.
Autocompletion Features
When you enter the FRR CLI, you see the following line:
At any time in the CLI, you can type ? to see all the possible commands you can currently type.
Some of the shown commands are:
router# ?
clear Reset functions
configure Configuration from vty interface
exit Exit current mode and down to previous mode
no Negate a command or set its defaults
ping Send echo messages
quit Exit current mode and down to previous mode
show Show running system information
traceroute Trace route to destination
write Write running configuration to memory, network, or terminal
For example, the command show will print various views of the
router state. To see what kind of information can be shown, just type
show ?. For example, show running-config will print the
running configuration.
The interfaces are not visible in the output at the beginning, but will start appearing as soon as you have configured them.
You can shorten the commands when there is no possible ambiguity.
For instance, show run is equivalent to show running-config.
Similarly to the Linux terminal, you can also use auto-completion by pressing the Tab key.
Testing Connectivity
If you want to test your connectivity, you can use ping or traceroute from the CLI of the routers.
Do you remember seeing both commands listed as available in the last command output?
However, whenever it is possible, consider testing connectivity from the hosts because they can use DNS whereas the routers in our setup cannot.
If you are not yet familiar with the strange zoo of tools like ping or traceroute, don’t worry; we will cover them in detail later on.
For now, notice that the CLI offers many tools, among them those for connectivity testing.
Switching to Configuration Mode
To configure your router, you must enter the configuration mode with configure terminal (conf t for the short version).
You can verify that you are in the configuration mode by looking for the config prefix in your CLI prompt.
Use exit to leave the configuration mode and return to the previous mode.
Commands that work in configuration mode do not (necessarily) work outside configuration mode and vice versa.
Notably, commands starting with show do not work in configuration mode.
Undo a Command
If you want to delete parts of the configuration, you can prefix the command you want to remove with no.
For example, try the following:
Log into a router of your choice, e.g. CAIR.
Then let it show you its interfaces by issuing:
Did it work? In which mode did you issue the command? Choose one interface. Then go into configuration mode for the interface, e.g.:
Now configure any IP-Address, e.g.:To delete the address, you can now simply run:
Additional Resources
Next week, you will have to design your own subnets and VLANs. Use the time until then to practice, practice, practice. You will have to do subnet calculations on the exam, and you will have to be fast.
Check out the following video for some practical hands-on knowledge on VLANs (which we will configure next week).
Cave
From a practical standpoint, VLANs and subnets go hand in hand, but for theory questions on the exam 
remember that they are not the same concept.
page version 1.0.2 - last edited June 2nd, 2024