|
|
|
|
@ -74,14 +74,60 @@ 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 in Firefox 116.0b2.
|
|
|
|
|
Also, we find the interface of Topolograph impractical to use (tested in
|
|
|
|
|
Firefox version 116.0b2).
|
|
|
|
|
|
|
|
|
|
\subsection{Summary of existing tools}
|
|
|
|
|
|
|
|
|
|
\X{table}
|
|
|
|
|
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\X{TODO}
|
|
|
|
|
\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}
|
|
|
|
|
|
