|
|
|
@ -1,19 +1,116 @@
|
|
|
|
|
\chapter*{Introduction}
|
|
|
|
|
\addcontentsline{toc}{chapter}{Introduction}
|
|
|
|
|
|
|
|
|
|
\section{Terminology}
|
|
|
|
|
Network administrators need to be aware of the
|
|
|
|
|
current state of their networks. While routing protocols like OSPF often need
|
|
|
|
|
to have complete information about the state of the networks, we did not find
|
|
|
|
|
an existing project that would visualise this data easily. We have therefore
|
|
|
|
|
created a rather simple program called Birdvisu, which aims to fill this hole.
|
|
|
|
|
|
|
|
|
|
\section{Notation}
|
|
|
|
|
Apart from visualising the topology, we provide the user with basic analysis
|
|
|
|
|
tools like showing the shortest path DAGs for routers. Furthermore, the
|
|
|
|
|
architecture of Birdvisu will allow enhancing the data from the routing
|
|
|
|
|
protocol with additional data, e.g. the utilization of particular links.
|
|
|
|
|
|
|
|
|
|
% Also note the use of Cisco icons
|
|
|
|
|
\X{mov?}While the primary motivation for implementing Birdvisu was the need of the
|
|
|
|
|
author, we believe that it might be useful for various OSPF deployments like
|
|
|
|
|
community wireless networks or homelabs\X{2x glos}.
|
|
|
|
|
|
|
|
|
|
\section{Structure of the thesis}
|
|
|
|
|
\section*{Terminology}
|
|
|
|
|
\addcontentsline{toc}{section}{Terminology}
|
|
|
|
|
|
|
|
|
|
In this thesis, we use the word \emph{host} to mean a device connected to a
|
|
|
|
|
network and capable of processing (sending, receiving, forwarding, \dots) IP packets.
|
|
|
|
|
|
|
|
|
|
An \emph{administrator} is a person or a group of people, who provide the
|
|
|
|
|
routers with configuration and who make sure that the routers (and other
|
|
|
|
|
infrastructure) functions correctly.
|
|
|
|
|
|
|
|
|
|
The word \emph{network} will always denote a set of hosts, that can exchange
|
|
|
|
|
packets \uv{directly}, without forwarding, under normal circumstances. While
|
|
|
|
|
this is somewhat synonymous with the term \emph{network segment}, when the
|
|
|
|
|
network splits, there may be multiple link-layer segments belonging to the same
|
|
|
|
|
network.
|
|
|
|
|
|
|
|
|
|
We say that a router is said to be \emph{incident} to a network when it has an
|
|
|
|
|
interface into it. For simplicity, we also say that that network is incident to
|
|
|
|
|
that router (that is, the incidence relation is symmetrical). We say that
|
|
|
|
|
a router is a \emph{neighbour} of another router, when they are incident to a
|
|
|
|
|
shared network, and conversely, that two networks are neighbours when they
|
|
|
|
|
share a router.
|
|
|
|
|
|
|
|
|
|
We will use the word \emph{network system} (or just \emph{system}) to describe a
|
|
|
|
|
set of network managed by a single administrator, which is intended to forward
|
|
|
|
|
packets across it. This can mean the whole autonomous system\footnote{This is
|
|
|
|
|
where we borrowed the word \uv{system} from.}, but often this is a much smaller
|
|
|
|
|
part. When we speak about routing using OSPF, a system is only the set of
|
|
|
|
|
networks that run a single instance of OSPF.
|
|
|
|
|
|
|
|
|
|
By the term \emph{IP} we mean the Internet Protocol of either version 4 or 6.
|
|
|
|
|
When it is important to distinguish, we explicitly write \emph{IPv4} or
|
|
|
|
|
\emph{IPv6}. IP may also denote an IP address, as in \uv{a router has an IP},
|
|
|
|
|
but this usage should be clear from the context.
|
|
|
|
|
|
|
|
|
|
We distinguish between \emph{routing} as the act of finding next hops\X{glos},
|
|
|
|
|
and \emph{forwarding}, the act of sending a received packet through an
|
|
|
|
|
interface according to a \emph{routing table}. (Whether the routing table is
|
|
|
|
|
distinct from the network-layer forwarding table is an implementation detail.)
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
\emph{graph} only when talking about visualisation of the network to
|
|
|
|
|
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
|
|
|
|
|
graph (as understood by graph theory).
|
|
|
|
|
|
|
|
|
|
\medskip
|
|
|
|
|
|
|
|
|
|
We will be using many other networking terms, which we hope are well-known, but
|
|
|
|
|
for the sake of completeness, we provide a \hyperref[ch:glossary]{glossary} and
|
|
|
|
|
a \hyperref[ch:abbrs]{list of abbreviations} at the end of this thesis.
|
|
|
|
|
|
|
|
|
|
\section*{Notation}
|
|
|
|
|
\addcontentsline{toc}{section}{Notation}
|
|
|
|
|
|
|
|
|
|
We write filenames and commands in monospace font, like in \texttt{rm -rf
|
|
|
|
|
/bin}. Snippets of code are also written in monospace, but when we speak of a
|
|
|
|
|
particular class in text, it is only capitalised, as in \uv{The keys of the
|
|
|
|
|
dictionary are VertexIDs}.
|
|
|
|
|
|
|
|
|
|
For network diagrams, we use the Network topology icons from
|
|
|
|
|
Cisco\cite{cisco-icons}. The basic icons are shown on
|
|
|
|
|
Figure~\ref{fig:basic-icons}.
|
|
|
|
|
|
|
|
|
|
\begin{figure}[h]
|
|
|
|
|
\centering
|
|
|
|
|
\begin{subfigure}[b]{0.3\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\X{Router}
|
|
|
|
|
\caption*{Router}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.3\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\X{Network}
|
|
|
|
|
\caption*{Network}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.3\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\X{Switch}
|
|
|
|
|
\caption*{Switch}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\caption{Basic Cisco network icons}
|
|
|
|
|
\label{fig:basic-icons}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
\section*{Structure of the thesis}
|
|
|
|
|
\addcontentsline{toc}{section}{Structure of the thesis}
|
|
|
|
|
|
|
|
|
|
%- motivation
|
|
|
|
|
% -tgt audience of birdvisu
|
|
|
|
|
% - previous work / other approaches to network monitoring
|
|
|
|
|
% - And why we do not like them
|
|
|
|
|
% - Problem statement / project goals
|
|
|
|
|
% - Non-goals
|
|
|
|
|
% - Non-goals and future goals
|
|
|
|
|
%- Analysis / Survey (behaviour of computer networks)
|
|
|
|
|
% - gennet as a method of testing behaviour
|
|
|
|
|
% - OSPF
|
|
|
|
@ -24,6 +121,7 @@
|
|
|
|
|
% - Project structure / overview
|
|
|
|
|
% - Annotators
|
|
|
|
|
% - handles
|
|
|
|
|
% - Handling expected expansion
|
|
|
|
|
%- Usage
|
|
|
|
|
%- Evaluation?
|
|
|
|
|
% - Home
|
|
|
|
|