1
0
Fork 0

Moar text

master
LEdoian 1 year ago
parent af97caa5af
commit f774054168

@ -172,8 +172,88 @@ 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.
Let us look in depth at the \texttt{show ospf state} command, since we will be
using it and the format of its output a lot.
The command has two optional parameters. First, the flag \texttt{all} may be
added to show details not only the reachable part of the system, but from all
the known and non-expired LSAs. The difference between the topologies can be
used to discover network problems even without configuring the expected state.
The second parameter is a name of the OSPF instance. It is only required when
BIRD is running multiple instances simultaneously. This is unfortunately quite
common, because in dual-stack\X{glos} systems there needs to be a separate
instance of OSPF configured for each IP version.
The output of the command is a tree of lines representing the topology itself.
Children of a directive are indented by one more tab. An example output is
shown in listing~\ref{lst:ospffile}.
\begin{lstlisting}[float=h,label=lst:ospffile,caption=Example OSPFv2 state output]
area 0.0.0.1
router 203.0.113.1
distance 20
network 203.0.113.0/26 metric 10
xnetwork 203.0.113.64/26 metric 10
xrouter 203.0.113.42 metric 10
router 201.0.113.2
distance 0
network 203.0.113.0/26 metric 20
external 0.0.0.0/0 metric 60
stubnet 201.0.113.128/25 metric 200
network 203.0.113.0/26
dr 203.0.113.1
distance 20
router 201.0.113.1
router 201.0.113.2
\end{lstlisting}
The tree as output by BIRD has three levels, we call them top-level, level-2
and level-3. The top level only contains directives of form \texttt{area
AreaID}, with the AreaID being written in the quad-dotted notation.
On level-2 are mentioned all the routers and networks in the area. This is
different for OSPFv2 and OSPFv3. While routers are always mentioned by their
router IDs (again, quad-dotted), networks in OSPFv2 dumps are addressed using
their IPv4 addresses (CIDR notation), but by the designated router ID and
interface number in OSPFv3 ones: \verb|network [203.0.113.1-23]|.
The third level describes details of the respective router/network and all the
incident objects. There is always the distance from us (i.e. the router we
asked for the dump), or the word \texttt{unreachable} if it is not reachable.
There is also a line for each incident host and network. For routers and
networks, this line is the same as on level-2, but routers may also be incident
to extra-area networks (\texttt{xnetwork}), external networks
(\texttt{external}), stub networks (\texttt{stubnet}) and extra-area routers
(\texttt{xrouter}). These networks are referenced by their IP address in both
versions of OSPF, routers again by router IDs.
These incidencies of routers have also a metric, after the word
\texttt{metric}, or, in case of Type 2 external cost, \texttt{metric2}.
For networks, additional details are also provided on level-3. For OSPFv2, the
designated router ID is given in the \texttt{dr} directive, similarly, OSPFv3
may provide the networks with zero or more \texttt{address} lines with CIDR
addresses. An example of a network block in OSPFv3 is in
listing~\ref{lst:ospfnet}.
\begin{lstlisting}[float=h,label=lst:ospfnet,caption=Example OSPFv3 network block]
network [198.51.100.1-16]
distance 10
router 198.51.100.1
router 198.51.100.2
address 2001:db0:b00:7::/64
\end{lstlisting}
One of the nice properties of BIRD's output is that whenever there is a level-3
incidence line for object B in a level-2 block of object A, there exists an
edge from A to B in the topology used by the Dijkstra's algorithm. This fact
will later simplify parsing.
\section{Test network system: Gennet}
@ -182,7 +262,7 @@ 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
Jinja2\cite{jinja2} templates, it provides a semi-automatic 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
@ -190,7 +270,7 @@ 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
a reproducible environment, 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.
@ -216,7 +296,7 @@ is explained in detail in Gennet's \texttt{README.md} file.
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
connectivity to network 7 and configure the machine X manually. We use
this exact topology as a base for our experimentation.
\X{fig:gennet}

@ -47,6 +47,9 @@
\usepackage{xcolor} % typesetting in color
\usepackage{csquotes}
\usepackage{subcaption}
\usepackage{listings}
\lstset{basicstyle=\ttfamily\footnotesize,captionpos=b,columns=fullflexible,numbers=left,numberstyle=\color{gray}\footnotesize}
\def\X#1{\textcolor{red}{[#1]}}
\def\XXX#1{\par\smallskip\noindent \textcolor{red}{[#1]}}

Loading…
Cancel
Save