Moar text

en/chap02.tex

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

en/header.tex

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