|
|
|
|
@ -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..}
|
|
|
|
|
|
