1
0
Fork 0

somr progress hopefully.

master
LEdoian 1 year ago
parent 7a773580ae
commit 1a8320648c

@ -1 +1 @@
\chapter{Motivation}\label{ch:motivation}

@ -1,4 +1,4 @@
\chapter{\X{Analysis?}} \chapter{Analysis}\label{ch:analysis}
In order to avoid as many problems as possible when visualising and In order to avoid as many problems as possible when visualising and
analysing a OSPF topology, we need to understand several aspects of networking, 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 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. 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 To aid in testing Birdvisu and experimenting with routing, we will also present
using a \uv{swarm} of virtual machines. 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} \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 getting a topology description. The following subsection describes the syntax of
the response to this command. the response to this command.
\subsection{Retrieving the OSPF state} \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..}

@ -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 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 \emph{graph} only when talking about visualisation of the network to
distinguish between the real state and a virtual one. Moreover, in 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). graph (as understood by graph theory).
\medskip \medskip
@ -105,8 +105,8 @@ Figure~\ref{fig:basic-icons}.
\section*{Structure of the thesis} \section*{Structure of the thesis}
\addcontentsline{toc}{section}{Structure of the thesis} \addcontentsline{toc}{section}{Structure of the thesis}
In the first chapter, we explore various approaches of visualising and In the \hyperref[ch:motivation]{first} chapter, we explore various approaches of visualising and
monitoring a network system. Then, in chapter \ref{ch:net}, we understand the monitoring a network system. Then, in chapter \ref{ch:analysis}, we understand the
behaviour of relevant networking technologies. From that, we derive a design behaviour of relevant networking technologies. From that, we derive a design
for Bidrvisu in chapter \ref{ch:design}. Chapter \ref{ch:usage} explains usage 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 of the program. At the end, we demonstrate how the project works in network

Loading…
Cancel
Save