You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
136 lines
6.1 KiB
TeX
136 lines
6.1 KiB
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 visualisation already exist.
|
|
These can be approximately split into several types: visualisation of existing
|
|
data, traffic visualisation, host monitoring systems and integrated system
|
|
management platforms. Here we introduce them shortly and explain their
|
|
potential disadvantages, compared to visualisation of routing information.
|
|
|
|
\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 this 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 retrieve 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 only one 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 disadvantages. Table~\ref{t:comparison1} summarizes known approaches.
|
|
|
|
\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, 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 of them
|
|
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 Help administrator quickly recognise issues in the network,
|
|
\item Allow to be enhanced by other data and to export own data to other
|
|
projects, in the future.
|
|
\end{itemize}
|