First pieces of the thesis.
Really commiting only so that it is shared across my devices.master
parent
9e751f5c29
commit
d24212a293
@ -1,5 +1,160 @@
|
|||||||
\chapter{Title of the second chapter}
|
\chapter{\X{Analysis?}}
|
||||||
|
|
||||||
\section{Title of the first subchapter of the second chapter}
|
In order to avoid as many problems as possible when visualising and
|
||||||
|
analysing a OSPF topology, we need to understand several aspects of networking,
|
||||||
|
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, so we only describe
|
||||||
|
enough details to be able to reason about the design of the implementation.
|
||||||
|
|
||||||
\section{Title of the second subchapter of the second chapter}
|
\section{OSPF overview}
|
||||||
|
|
||||||
|
OSPF is a link-state routing protocol, which means that routers try to understand
|
||||||
|
the whole topology of the network and find the best path using an algorithm for
|
||||||
|
finding the shortest paths. Usually, Dijkstra's algorithm \X{ref?} is used.
|
||||||
|
OSPF was designed to provide dynamic routing in a whole autonomous system, but
|
||||||
|
running it on a much smaller scale is also possible.
|
||||||
|
|
||||||
|
OSPF requires routers to share information about the state of the topology in
|
||||||
|
messages called \emph{Link State Advertisements} (or LSAs for short). The LSAs
|
||||||
|
contain information about which network segments are adjacent \X{term} to which
|
||||||
|
router on which interfaces and with which routers it is possible to communicate
|
||||||
|
on those interfaces. To distinguish between routers, each router is assigned a
|
||||||
|
32-bit number called \emph{Router ID} by the network administrator \X{term}.
|
||||||
|
Router IDs are usually written in a quad-dotted notation \X{glos}.
|
||||||
|
|
||||||
|
The LSAs are flooded throughout the system in order to let all the routers know
|
||||||
|
about the current topology. To avoid overloading the system just with this
|
||||||
|
routing traffic, OSPF devises several mechanisms of minimising the number of
|
||||||
|
exchanged messages. First, each network elects a \emph{designated router} (or
|
||||||
|
DR) which coordinates exchange of the messages in that network segment.
|
||||||
|
Second, the system can be partitioned into \emph{areas}. That way, the frequent
|
||||||
|
LSAs are only flooded throughout a limited set of networks; the \emph{area
|
||||||
|
border routers} send accumulated LSAs into other areas.\footnote{These
|
||||||
|
inter-area LSAs are called \uv{Summary LSAs}, but there is no requirement that
|
||||||
|
the routing information is actually aggregated.} These LSAs do not describe the
|
||||||
|
topology of the originating area.
|
||||||
|
|
||||||
|
The area 0.0.0.0 is called the \emph{backbone area} and all other areas must be
|
||||||
|
adjacent to it, so that it has all the routing information. When this is
|
||||||
|
impractical, OSPF allows two routers to be connected using a \emph{virtual
|
||||||
|
link}. From the routing perspective, this is a point-to-point connection
|
||||||
|
between the routers in the backbone area. which allows to forward LSAs through
|
||||||
|
other areas even when these LSAs would not normally leave those areas.
|
||||||
|
|
||||||
|
There are several types of networks that emerge in OSPF topologies. The
|
||||||
|
\emph{transit} networks are used for forwarding packets in an area. \emph{Stub}
|
||||||
|
networks only have one router and therefore can only deliver packets
|
||||||
|
originating from or destinated to that network. For representing routes outside
|
||||||
|
of the area and the whole system, OSPF recognises \emph{extra-area} and
|
||||||
|
\emph{external} networks respectively. It is also possible for a router to be
|
||||||
|
adjacent to an extra-area router through a point-to-point link.
|
||||||
|
|
||||||
|
Once the router has complete information about the topology of an area, it
|
||||||
|
constructs a graph representation of the network and calculates the shortest path
|
||||||
|
DAG\footnote{In the specifications, it is called the shortest path \emph{tree},
|
||||||
|
but there may be multiple shortest paths and the router is supposed to use all
|
||||||
|
of them.} rooted at that router. This DAG is then used for finding shortest
|
||||||
|
paths to routers and networks in that area, including the external, extra-area
|
||||||
|
and stub networks adjacent to that area. OSPF specifies that the graph has all
|
||||||
|
the networks and routers as vertices, directed edges lead from each router to the
|
||||||
|
incident network with the configured cost and from each transit network to
|
||||||
|
incident routers with cost 0 (except when the two-part metric\cite{rfc8042} is
|
||||||
|
implemented). There are no edges starting at the external, extra-area or stub
|
||||||
|
networks, so that the shortest path DAG calculation does not find paths
|
||||||
|
through them.
|
||||||
|
|
||||||
|
The cost of the edge to an external network can be of two types. Type 1 cost is
|
||||||
|
specified in the same units as the internal costs, Type 2 cost is larger than
|
||||||
|
any internal or type 1 cost.
|
||||||
|
|
||||||
|
The OSPF family of routing protocols has undergone long evolution since the
|
||||||
|
first specification in 1989\cite{rfc1131}, There are currently two versions of
|
||||||
|
the protocol in use -- versions 2 and 3. While the basic idea is still the
|
||||||
|
same, OSPFv2 can only handle IPv4 systems. While OSPFv3 claims to be
|
||||||
|
network-protocol-independent, it is usually only used with IPv6 systems and in
|
||||||
|
fact, features like virtual links can only be used with that network
|
||||||
|
protocol\cite{rfc5838}.
|
||||||
|
|
||||||
|
Both OSPF versions have numerous extensions, as can be seen by the number of
|
||||||
|
RFCs that update the base specifications\cite{rfc2328,rfc5340}. Therefore, we
|
||||||
|
do not implement the protocol ourself, but rather find a suitable routing
|
||||||
|
daemon \X{glos} to determine the current topology.
|
||||||
|
|
||||||
|
\section{Routing daemon selection}
|
||||||
|
|
||||||
|
While we were mostly determined to use BIRD\cite{bird} from the start, since we already
|
||||||
|
had some experience with it, let us present here a short summary of other
|
||||||
|
possibilities.
|
||||||
|
|
||||||
|
There are several implementations of both versions of the OSPF protocol.
|
||||||
|
However, many of them are tied to the specific router hardware, which makes it
|
||||||
|
impractical to connect to a graphical visualisation. Moreover, even evaulating
|
||||||
|
the feasibility would require us to obtain the specific hardware. Therefore, we
|
||||||
|
only consider hardware-independent solutions.
|
||||||
|
|
||||||
|
While we are aware of several software implementations, many of these do not
|
||||||
|
seem to be developed anymore (Quagga\cite{quagga}, XORP\cite{xorp},
|
||||||
|
OpenOSPFd\cite{openospfd}). Apart from BIRD, we only found FRRouting\cite{frr}
|
||||||
|
to be maintained, meaning that it had a release in the past year. While being
|
||||||
|
maintained is not a strict requirement, it would allow us to use that
|
||||||
|
implementation in case OSPF is extended again.
|
||||||
|
|
||||||
|
However, even BIRD does not implement all the extensions, for example, the
|
||||||
|
two-part metric\cite{rfc8042}.
|
||||||
|
|
||||||
|
\section{BIRD interface}
|
||||||
|
|
||||||
|
The BIRD daemon is controlled through a UNIX domain socket using a text
|
||||||
|
line-based protocol slightly resembling SMTP\X{cite?}. The client may send
|
||||||
|
commands to the daemon, which provides responses. The response may be long and
|
||||||
|
possibly formatted into a table. This interface is primarily aimed at human
|
||||||
|
users, so a rather simple client, \texttt{birdc}, is provided in the BIRD's
|
||||||
|
package\X{glos?}.
|
||||||
|
|
||||||
|
While there is a note of a machine-readable protocol in the
|
||||||
|
\texttt{doc/roadmap.md} file in BIRD's source code\cite{bird-src}, it is not
|
||||||
|
implemented, so we will need to interface using the socket. This has following
|
||||||
|
consequences, most of which are not very pleasant:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item The responses to different formats often have completely different
|
||||||
|
formats. This necessitates creating a dedicated parsing routines for each kind
|
||||||
|
of command we want to use.
|
||||||
|
\item There is no guarantee that the output will not change between versions.
|
||||||
|
We might need to follow BIRD's development in order to be aware of possible
|
||||||
|
changes.
|
||||||
|
\item The output does not contain all details of BIRD's state. For example, we
|
||||||
|
can not retrieve the shortest path DAG directly from BIRD, nor see the details
|
||||||
|
of the individual LSAs.
|
||||||
|
\item There is no way to get notified when the topology changes.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
BIRD provides only a few commands that deal with OSPF:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \texttt{show ospf} shows a simple summary of the running instances of
|
||||||
|
OSPF, like which areas are they in or how many LSAs does BIRD currently
|
||||||
|
consider.
|
||||||
|
\item \texttt{show ospf interface} describes a current status of the individual
|
||||||
|
local interfaces: their configuration, designated routers for the incident
|
||||||
|
network, etc.
|
||||||
|
\item \texttt{show ospf neighbors} provides details about the state of
|
||||||
|
communication with adjacent routers.
|
||||||
|
\item \texttt{show ospf lsadb} returns details about known LSAs. Unfortunately,
|
||||||
|
this contains low-level information like checksums and sequence numbers,
|
||||||
|
but not details about networks or routers.
|
||||||
|
\item \texttt{show ospf state} shows an overal view of the ospf graph
|
||||||
|
representation: present routers and networks, costs of links, distances, \dots
|
||||||
|
\item \texttt{show ospf topology} seems to only provide a subset of the output
|
||||||
|
of \texttt{show ospf state}. For example, it does not provide info about
|
||||||
|
any non-transit networks.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Even though some of the commands can have more parameters, parsing the output
|
||||||
|
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}
|
||||||
|
|||||||
@ -0,0 +1,34 @@
|
|||||||
|
\chapter*{Introduction}
|
||||||
|
\addcontentsline{toc}{chapter}{Introduction}
|
||||||
|
|
||||||
|
\section{Terminology}
|
||||||
|
|
||||||
|
\section{Notation}
|
||||||
|
|
||||||
|
\section{Structure of the thesis}
|
||||||
|
|
||||||
|
%- motivation
|
||||||
|
% -tgt audience of birdvisu
|
||||||
|
% - previous work / other approaches to network monitoring
|
||||||
|
% - Problem statement / project goals
|
||||||
|
% - Non-goals
|
||||||
|
%- Analysis / Survey (behaviour of computer networks)
|
||||||
|
% - gennet as a method of testing behaviour
|
||||||
|
% - OSPF
|
||||||
|
% - BIRD + caveats
|
||||||
|
% - Idiosyncracies of
|
||||||
|
%- Design
|
||||||
|
% - Technologies
|
||||||
|
% - Project structure / overview
|
||||||
|
% - Annotators
|
||||||
|
% - handles
|
||||||
|
%- Usage
|
||||||
|
%- Evaluation?
|
||||||
|
% - Home
|
||||||
|
% - KAM
|
||||||
|
%- Conclusion
|
||||||
|
%
|
||||||
|
% References?
|
||||||
|
%
|
||||||
|
% Glossary
|
||||||
|
% List of abbreviations
|
||||||
@ -1,3 +0,0 @@
|
|||||||
\chapter*{Introduction}
|
|
||||||
\addcontentsline{toc}{chapter}{Introduction}
|
|
||||||
|
|
||||||
@ -1,7 +1,7 @@
|
|||||||
% Metadata to be stored in PDF, see documentation of the pdfx package for more details.
|
% Metadata to be stored in PDF, see documentation of the pdfx package for more details.
|
||||||
|
|
||||||
\Author{Name Surname}
|
\Author{Pavel Turinský}
|
||||||
\Title{Thesis title}
|
\Title{Visualizing OSPF topology}
|
||||||
\Keywords{keywords\sep more such\sep yet another}
|
\Keywords{keywords\sep more such\sep yet another}
|
||||||
\Subject{Abstract of thesis}
|
\Subject{Abstract of thesis}
|
||||||
\Publisher{Charles University}
|
\Publisher{Charles University}
|
||||||
|
|||||||
Loading…
Reference in New Issue