From 1a8320648ca07997a793b9f543d1e3161183077d Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Sat, 15 Jul 2023 21:11:50 +0200 Subject: [PATCH] somr progress hopefully. --- en/chap01.tex | 2 +- en/chap02.tex | 67 +++++++++++++++++++++++++++++++++++++++++++++++---- en/intro.tex | 6 ++--- 3 files changed, 66 insertions(+), 9 deletions(-) diff --git a/en/chap01.tex b/en/chap01.tex index 8b13789..6241fe0 100644 --- a/en/chap01.tex +++ b/en/chap01.tex @@ -1 +1 @@ - +\chapter{Motivation}\label{ch:motivation} diff --git a/en/chap02.tex b/en/chap02.tex index eb9c17f..4097d0b 100644 --- a/en/chap02.tex +++ b/en/chap02.tex @@ -1,4 +1,4 @@ -\chapter{\X{Analysis?}} +\chapter{Analysis}\label{ch:analysis} In order to avoid as many problems as possible when visualising and analysing a OSPF topology, we need to understand several aspects of networking, @@ -6,8 +6,10 @@ the OSPF protocol and its implementation in BIRD. However, the aim of this thesis is not to be a complete guide to OSPF nor BIRD, therefore, for the sake of brevity, we skip many details which do not influence our project. -Later in this chapter we also present a way to simulate uncommon network states -using a \uv{swarm} of virtual machines. +To aid in testing Birdvisu and experimenting with routing, we will also present +a small side-project called Gennet in this chapter. Using it, we will +understand the behaviour of network splits and multiple links, as seen by the +BIRD routing daemon. \section{OSPF overview} @@ -169,6 +171,61 @@ of the \texttt{show ospf state} command is still the only the viable option of getting a topology description. The following subsection describes the syntax of the response to this command. - - \subsection{Retrieving the OSPF state} +... +% ospffile format, differences b/w v2 and v3, several snippets. + +\section{Test network system: Gennet} + +To help test Birdvisu and understand network behaviour, we created a simple set +of scripts called Gennet. Sice it was mainly written to aid Birdvisu, we +provide it as attachment~\ref{att:gennet} of this thesis. + +Gennet is a network generator. Using a hard-coded configuration and a set of +Jinja2\cite{jinja2} templates, it provides a semi-automatic\X{term?} way of +creating several virtual machines (their disk images and startup scripts) and +configuration to connect them using software bridges\X{term?}. This will allow +changing the state from the host operating system, simulating various network +conditions. + +We fully admit that Gennet is really just a quick hack. However, since it was +created specifically to aid the development of Birdvisu and because it provides +some reproducibility, we think it makes sense to attach it to this thesis. The +particular choice of technologies (Jinja2, Python, Bash, QEMU and Alpine +Linux)\X{refs!} is driven solely by our previous experience with them and +should not affect the behaviour of the generated system in any way. + +%Gennet is used as follows: the user must first generate a base Linux image, +%\verb|dummydisk.img|. Then, startup scripts and configuration files for the +%individual machines are created in the \verb|output/| directory. These files +%are then added into the copies of the base image using the +%\verb|gen_disks.sh| script. Now it is possible to create the bridges using +%\verb|output/gen_bridges.sh| and allow QEMU to attach VMs to these bridges by +%appending the contents of \verb|output/bridge.conf| into +%\verb|/etc/qemu/bridge.conf|. Finally, machines may be started, either by +%running \verb|qemu.sh| in the output directory for each machine, or using +%\verb|./manage_all.sh start| as a shortcut. +Using Gennet generally involves creating a base disk image and configuration +for individual machines, embedding this configuration into the base image, +configuring the bridges and finally starting the required machines. The process +is explained in detail in Gennet's \texttt{README.md} file. +% I hope it is OK to just link this. I do not want to reword this again, since +% this is completely unimportant and nobody should care unless they need to use +% it, in which case they must read the README anyways. + +When used without changing Gennet's configuration, it creates a topology of 10 +routers (A--I, X) and 7 networks (numbered), as shown in +figure~\ref{fig:gennet}. We expect the user to provide some network +connectivity to network 7 and configuring the machine X accordingly. We use +this exact topology as a base for our experimentation. + +\X{fig:gennet} + +\section{Unusual network states}\label{s:net-unusual} + +Now that we have basic understanding of BIRD and a network system for testing, +we see how both versions of OSPF react to various unusual conditions in the +system. + +\XXX{netsplit, multi links w/ same and diff costs, v2 vs v3, mixed segments, +multiple prefixes. napsat na kolejích s gennetem..} diff --git a/en/intro.tex b/en/intro.tex index 5038e7e..13bd901 100644 --- a/en/intro.tex +++ b/en/intro.tex @@ -60,7 +60,7 @@ A \emph{topology} describes the connections in the network system, i.e. which router is connected to which networks, with what costs etc. We use the term \emph{graph} only when talking about visualisation of the network to distinguish between the real state and a virtual one. Moreover, in -section~\ref{s:net-idiosyncracies} we will see that a topology is in fact not a +section~\ref{s:net-unusual} we will see that a topology is in fact not a graph (as understood by graph theory). \medskip @@ -105,8 +105,8 @@ Figure~\ref{fig:basic-icons}. \section*{Structure of the thesis} \addcontentsline{toc}{section}{Structure of the thesis} -In the first chapter, we explore various approaches of visualising and -monitoring a network system. Then, in chapter \ref{ch:net}, we understand the +In the \hyperref[ch:motivation]{first} chapter, we explore various approaches of visualising and +monitoring a network system. Then, in chapter \ref{ch:analysis}, we understand the behaviour of relevant networking technologies. From that, we derive a design for Bidrvisu in chapter \ref{ch:design}. Chapter \ref{ch:usage} explains usage of the program. At the end, we demonstrate how the project works in network