bc_thesis/en/chap01.tex

\chapter{Motivation}\label{ch:motivation}

%First, we need to further specify, what Birdvisu should be. This section
%describes what is the missing project and why such project would be useful.

In this chapter we explore existing solutions for visualising and monitoring
network systems and describe the requirements of network administrators. From
this we derive a set of properties Birdvisu should fulfil.

\section{Existing approaches to network monitoring}

Several approaches to network monitoring and status visalisation already exist.
These can be approximately split into several types: visualisation of existing
data, traffic visualisation, host monitoring systems and integrated system
management platforms. We \X{uuuuuuuuuu}.

\subsection{Visualisation of existing data}

Tools in this category do not collect any data on their own, rather only
focusing on visualising data from other tools. These projects are often small,
can be easy to run and allow visualisation of various data, but they require
other infrastructure to provide the data. For example, the Network
Weathermap\cite{weathermap} project can be used to provide overview based on
data in Cacti or other tools. Grafana\cite{grafana} provides many different
methods of visualising data from various databases.

This does not seem to be usable for visualising OSPF state, because we are not
aware of any collectors of OSPF state data.

\subsection{Traffic visualisation}

Various software packages can collect and graph utilisation of network links.
This often provides information about link state, but requires collection of
data on all hosts. Also, in some cases, this might not provide accurate data of
the system state, as we will see in section~\ref{s:net-split}.

These projects usually store a time series of utilisation and therefore need to
be deployed on some central server as long-running services.

Examples of this approach include Cacti\cite{cacti} and Munin\cite{munin}.
Although both mentioned projects can graph other data, plugins for data
collection are available, so this differentiates them from the previous group.

\subsection{Host monitoring systems}

Projects in tis category do not necessarily consider the whole network system,
but check state of individual hosts. It is possible for them to run locally, as
is the case for Plotnetcfg\cite{plotnetcfg}, or check the host over the network
(CaLStats\cite{calstats}, Icinga\cite{icinga}), but they do not provide
overall picture. The capabilities of these tools also differ, from just
checking reachability (CaLStats) to being able to retreive various details from
the hosts (Icinga, plotnetcfg).

This approach can also miss some issues with the system, as described in the
section~\ref{s:net-split}.

\subsection{Integrated system management platforms}

Some network administrators have created platforms for managing the hosts
across the network system. These systems usually know various aspects of the
system and may provide features like configuration generation or topology
visualisation\cite{nodewatcher-paper}. However, many of these are tailored for
the specific system and are therefore not reusable in other environments.

Also, since large number of people need to access such platforms, they are
usually server based with web interface\cite{nodewatcher-paper}.

\subsection{Topolograph}

We are aware of the only project that would allow visualisation of OSPF
topology, Topolograph\cite{topolograph}. While it does not collect its own
data, its companion project, Ospfwatcher\cite{ospfwatcher}, is able to retrieve
current topology data from a Quagga\cite{quagga} routing daemon. The deployment
involves setting up Logstash\cite{logstash}, so this is only suitable to be run
on a server.

Also, we find the interface of Topolograph impractical to use (tested in
Firefox version 116.0b2).

\subsection{Summary of existing tools}

As we have seen, various projects are available, but they often have some
important disadvantage. Table~\ref{t:comparison1} summarizes available projects.

\bgroup
\def\yes{\checkmark}
\def\no{\texttimes}
\def\maybe{?}
\begin{table}[h]
	\centering
	\begin{tabular}{lccccc}\hline
		Approach                  & CD   & RS     & CoH    & EoD    & T    \\\hline
		Only visualisation        & \no  & \maybe & \no    & \maybe & \no  \\
		Traffic visualisation     & \yes & \yes   & \yes   & \no    & \no  \\
		Host monitoring           & \yes & \maybe & \yes   & \maybe & \no  \\
		Integrated management     & \yes & \yes   & \maybe & \no    & \yes \\
		Topolograph + Ospfwatcher & \yes & \yes   & \no    & \no    & \yes \\\hline
		Ideal state               & \yes & \no    & \no    & \yes   & \yes \\
	\hline\end{tabular}
	\caption{Comparison of current approaches. CD: Can collect data on its own,
	RS: Requires to be deployed on a server, CoH: Collects data on individual
	hosts, EoD: Easy to deploy, T: Understands the topology of the system.}
	\label{t:comparison1}
\end{table}
\egroup

\section{Target group of users}

Birdvisu aims to be a rather simple tool for small to medium-sized network
systems, where it is impractical to deploy complex monitoring and visualisation
infrastructure. We want to especially help in homelabs and community wireless
networks\X{glos}, but any OSPF deployment should be able to make use of our
project.

Also, since we do not require any server apart from a routing daemon, which can
be running on any laptop, Birdvisu might also be a helpful tool for admins in
the field trying to fix broken infrastructure.

The primary motivation for implementing Birdvisu was the need of the author,
who has a dynamically routed system that switches uplinks depending on which
currently work. % Pls don't tell the dorms :-)

\section{Goals of Birdvisu}

We want Birdvisu to:

\begin{itemize}
	\item Be a simple tool, easy to run on a regular laptop
	\item Leverage the knowledge of topology, which is common in the system,
		without needing to collect data from other hosts
	\item Allow to be enhanced by other data and to export own data to other
		projects, in the future.
\end{itemize}