Compare commits
20 Commits
| Author | SHA1 | Date |
|---|---|---|
 LEdoian
|
7941e4fd7b | 1 year ago |
|
LEdoian
|
38b03f9260 | 1 year ago |
|
LEdoian
|
e8d27aecf1 | 1 year ago |
|
LEdoian
|
2c8b1b662d | 1 year ago |
|
LEdoian
|
4e378aed09 | 1 year ago |
|
LEdoian
|
65b4afe9b2 | 1 year ago |
|
LEdoian
|
fbb39dafea | 1 year ago |
|
LEdoian
|
4104e99f00 | 1 year ago |
|
LEdoian
|
f7a7dd97b1 | 1 year ago |
|
LEdoian
|
4d34100c91 | 1 year ago |
|
LEdoian
|
411173c7c6 | 1 year ago |
|
LEdoian
|
8676c18fb4 | 1 year ago |
|
LEdoian
|
4916c8f8f1 | 1 year ago |
|
LEdoian
|
c54e6059b0 | 1 year ago |
|
LEdoian
|
a5551ebfc8 | 1 year ago |
|
LEdoian
|
8d8da44c50 | 1 year ago |
|
LEdoian
|
874454904f | 1 year ago |
|
LEdoian
|
a18e295a9e | 1 year ago |
|
LEdoian
|
0ce9d5c321 | 1 year ago |
|
LEdoian
|
5c1cb432ee | 1 year ago |
@ -1,5 +1,5 @@
|
|||||||
% Metadata k uložení do PDF, podrobnější popis viz dokumentace balíčku pdfx.
|
% Metadata k uložení do PDF, podrobnější popis viz dokumentace balíčku pdfx.
|
||||||
|
|
||||||
\Author{Jméno Příjmení}
|
\Author{Pavel Turinský}
|
||||||
\Title{Název práce}
|
\Title{Vizualizace topologie OSPF}
|
||||||
\Publisher{Univerzita Karlova}
|
\Publisher{Univerzita Karlova}
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 211 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
@ -0,0 +1,289 @@
|
|||||||
|
\documentclass{beamer}
|
||||||
|
|
||||||
|
\usetheme{Madrid}
|
||||||
|
% Ref: https://tex.stackexchange.com/a/692
|
||||||
|
\setbeamertemplate{navigation symbols}{}
|
||||||
|
|
||||||
|
% We may as well create a PDF/A, why not. (I am too lazy to invent my
|
||||||
|
% own header, instead I just pick line from the thesis' one :-))
|
||||||
|
|
||||||
|
\usepackage[a-2u]{pdfx}
|
||||||
|
\usepackage[utf8]{inputenc}
|
||||||
|
\usepackage{lmodern}
|
||||||
|
|
||||||
|
\usepackage{xcolor}
|
||||||
|
\usepackage{listings}
|
||||||
|
|
||||||
|
\hypersetup{unicode}
|
||||||
|
\hypersetup{breaklinks=true}
|
||||||
|
|
||||||
|
\def\uv#1{``#1''}
|
||||||
|
|
||||||
|
|
||||||
|
\title{Visualising OSPF topology}
|
||||||
|
\subtitle{Motivation and design of Birdvisu} %FIXME?
|
||||||
|
\author{Pavel Turinský}
|
||||||
|
\date{7 September 2023}
|
||||||
|
%\date{07-09-2023} % Looks weird imho :-/
|
||||||
|
|
||||||
|
\begin{document}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\titlepage
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\iffalse % Maybe drop, in that case, comment the next line.
|
||||||
|
%\else
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Outline}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Introduction
|
||||||
|
\begin{itemize}
|
||||||
|
\item What is Birdvisu
|
||||||
|
\item Reasons for creating Birdvisu
|
||||||
|
\item Goals
|
||||||
|
\end{itemize}
|
||||||
|
% intro:
|
||||||
|
%% what
|
||||||
|
%% why (comparison)
|
||||||
|
%% goals
|
||||||
|
\item Technologies
|
||||||
|
\begin{itemize}
|
||||||
|
\item OSPF overview
|
||||||
|
\item Interaction with BIRD
|
||||||
|
\end{itemize}
|
||||||
|
% tech stack
|
||||||
|
%% OSPF summary + history
|
||||||
|
%% BIRD: why and how
|
||||||
|
%%% the dump format
|
||||||
|
%%% note gennet
|
||||||
|
\item Design
|
||||||
|
\begin{itemize}
|
||||||
|
\item Retrieving topologies
|
||||||
|
\item Annotation
|
||||||
|
\item Drawing
|
||||||
|
\end{itemize}
|
||||||
|
% design
|
||||||
|
%% the three phases
|
||||||
|
\item Results
|
||||||
|
\begin{itemize}
|
||||||
|
\item Small networks
|
||||||
|
\item Large: czela.net
|
||||||
|
\end{itemize}
|
||||||
|
% results
|
||||||
|
%% czela,net
|
||||||
|
%%% known deficiencies
|
||||||
|
|
||||||
|
\item Future
|
||||||
|
% future?
|
||||||
|
%% exports, integration
|
||||||
|
%% saving layouts
|
||||||
|
% gennet?
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
\fi
|
||||||
|
|
||||||
|
%TODO: slide about Birdvisu is, very highlevel
|
||||||
|
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Project goals}
|
||||||
|
The Birdvisu project aims to present the network topology, as known
|
||||||
|
by OSPF, to the administrator and allow them to analyse it.
|
||||||
|
|
||||||
|
\bigskip
|
||||||
|
|
||||||
|
Goals:
|
||||||
|
\begin{itemize}
|
||||||
|
\item As independent on other services as possible
|
||||||
|
\item Easy deployment
|
||||||
|
\begin{itemize}
|
||||||
|
\item Runnable on admin's laptop
|
||||||
|
\end{itemize}
|
||||||
|
\item No changes to other hosts required
|
||||||
|
\item It should be easy to create new analysis tools
|
||||||
|
\item Target: administrators of homelabs to middle-sized systems
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\medskip
|
||||||
|
|
||||||
|
To our knowledge, there is no such application yet.
|
||||||
|
|
||||||
|
\medskip
|
||||||
|
|
||||||
|
Birdvisu is implemented in Python 3 and Qt 6.
|
||||||
|
\end{frame}
|
||||||
|
% \begin{frame}
|
||||||
|
% %\frametitle{Why visualise/analyse topologies}
|
||||||
|
% \frametitle{Motivation and goals}
|
||||||
|
% Existing analysis/monitoring tools:
|
||||||
|
% \begin{itemize}
|
||||||
|
% \item Need to collect data on individual hosts,
|
||||||
|
% \item do may not have accurate data (network splits)
|
||||||
|
% \item or need to be deployed on a server
|
||||||
|
% \end{itemize}
|
||||||
|
% \dots yet in systems routed by OSPF each router knows all of this.
|
||||||
|
%
|
||||||
|
% \vfill
|
||||||
|
%
|
||||||
|
% The aim of Birdvisu is to present this information to
|
||||||
|
% administrators.
|
||||||
|
% \begin{itemize}
|
||||||
|
% \item single-host, easy-to-run, few dependencies on services
|
||||||
|
% \item Target: administrators of homelabs to middle-sized systems
|
||||||
|
% \end{itemize}
|
||||||
|
% \end{frame}
|
||||||
|
|
||||||
|
% TODO: wanted features?
|
||||||
|
|
||||||
|
%%% design
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Birdvisu design}
|
||||||
|
% uwu uwu FIXME TODO
|
||||||
|
The program consists of three main steps:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Obtaining the topologies
|
||||||
|
% shenanigans?
|
||||||
|
% non-matchability of uwu uwu.
|
||||||
|
\begin{itemize}
|
||||||
|
\item Reference (from file), current state
|
||||||
|
\item Representation: weighted directed multigraph
|
||||||
|
% \item Reference and current one merged into a single object
|
||||||
|
% \item Extracted from BIRD or loaded from saved files
|
||||||
|
% \item Networks can have various forms: orieiwnted weighted multigraph
|
||||||
|
\end{itemize}
|
||||||
|
\item Annotating
|
||||||
|
\begin{itemize}
|
||||||
|
\item Extending the topology with analysis results, other data, \dots
|
||||||
|
% \item Many single-purpose annotators
|
||||||
|
% \item e.g. compute topology differences, find shortest paths
|
||||||
|
\end{itemize}
|
||||||
|
\item Displaying the result
|
||||||
|
% own try of layouting alg
|
||||||
|
% each highlight has its StyleAnnotator
|
||||||
|
\begin{itemize}
|
||||||
|
\item Reduction of the topology to a simple graph
|
||||||
|
\item Highlight relevant annotator results
|
||||||
|
|
||||||
|
\medskip
|
||||||
|
|
||||||
|
\item Alternatively export the annotated topology (in future)
|
||||||
|
% \item Use Qt's features: dragging, interaction
|
||||||
|
% \item Layout loaded from file or determined by ad-hoc
|
||||||
|
% algorithm
|
||||||
|
% \item Reuses Annotator design
|
||||||
|
\end{itemize}
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{OSPF}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Link-state IGP: routers share information about the current state of the system
|
||||||
|
\item Long evolution (1989), multiple extensions, rather complex
|
||||||
|
\item Different versions for IPv4 and IPv6 routing
|
||||||
|
\begin{itemize}
|
||||||
|
\item Same idea, quite different internals
|
||||||
|
\end{itemize}
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\bigskip
|
||||||
|
|
||||||
|
Instead of implementing OSPF ourselves, we extract the state from existing routing daemon.
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{BIRD Internet Routing Daemon}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Originally SW project at this faculty, now maintained by CZ.NIC
|
||||||
|
\item Experience from deployment at home, Dept{.} of Applied Mathematics
|
||||||
|
\item One of two maintained OSPF daemons for general-purpose HW %FIXME: check BrE
|
||||||
|
\begin{itemize}
|
||||||
|
\item future extensions more likely to be implemented
|
||||||
|
\end{itemize}
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\bigskip
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Currently no machine-readable export
|
||||||
|
\begin{itemize}
|
||||||
|
\item The output for humans contains sufficient information
|
||||||
|
\end{itemize}
|
||||||
|
\item No dynamic output -- needs polling
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
% logo? snippet of output?
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Annotators}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Can add arbitrary$^*$ data to vertices and edges
|
||||||
|
\begin{itemize}
|
||||||
|
\item Exportable in future
|
||||||
|
\end{itemize}
|
||||||
|
\item Can depend on each other
|
||||||
|
\item Idea: many simple and single-purpose annotators
|
||||||
|
\item Uses: analysis, providing additional information, \dots
|
||||||
|
\begin{itemize}
|
||||||
|
\item e.g. comparing topologies, finding shortest path DAGs
|
||||||
|
\end{itemize}
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Visualisation}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Reuse Annotators for styling vertices and edges
|
||||||
|
\item Reduce topology to a simple graph by taking the most relevant edge
|
||||||
|
\begin{itemize}
|
||||||
|
\item lightest edge with positive cost
|
||||||
|
\end{itemize}
|
||||||
|
\item Layout can be loaded from a file
|
||||||
|
\begin{itemize}
|
||||||
|
\item New vertices placed to proximity of neighbours
|
||||||
|
\end{itemize}
|
||||||
|
\item Qt provides UI features: dragging, context menus
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
% Results and examples
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Small network example: Gennet}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[keepaspectratio,height=0.7\textheight]{gennet.png}
|
||||||
|
\\
|
||||||
|
Highlighting differences from expectation on a test network (Gennet)
|
||||||
|
\end{center}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Medium-sized network: Czela.net}
|
||||||
|
Community network system in Čelákovice, 45 routers, 210 networks (incl. external), about 1600 people
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[keepaspectratio,height=0.6\textheight]{czmess.png}
|
||||||
|
\\
|
||||||
|
Our layouting approach is not great without any initial placements.
|
||||||
|
\end{center}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Fixing Czela.net}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[keepaspectratio,height=0.7\textheight]{czbug.png}
|
||||||
|
\\
|
||||||
|
Misconfiguration, found after some dragging of vertices
|
||||||
|
\end{center}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\begin{center}
|
||||||
|
\begin{Large}
|
||||||
|
Thank you!
|
||||||
|
\end{Large}
|
||||||
|
\end{center}
|
||||||
|
\end{frame}
|
||||||
|
\end{document}
|
||||||
@ -1,5 +1,5 @@
|
|||||||
% 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}
|
||||||
\Publisher{Charles University}
|
\Publisher{Charles University}
|
||||||
|
|||||||
@ -1 +1,70 @@
|
|||||||
\chapter{Usage}\label{ch:usage}
|
\chapter{Usage}\label{ch:usage}
|
||||||
|
|
||||||
|
% Maybe this is too much of a guide, but I think a section with the user's
|
||||||
|
% description should be present and there is not much other content to write
|
||||||
|
% here. Also, the UI is currently horrible, so it is worth having this
|
||||||
|
% somewhere, and since there is no documentation, here is the place probably.
|
||||||
|
|
||||||
|
In this chapter we describe the program from the user's point of view and
|
||||||
|
present its features.
|
||||||
|
|
||||||
|
\section{Running Birdvisu}
|
||||||
|
|
||||||
|
First, the user needs to obtain Birdvisu from somewhere. Either, the
|
||||||
|
attachment~\ref{att:birdvisu} can be extracted, or the project can be
|
||||||
|
downloaded from its repository at
|
||||||
|
\url{https://gitea.ledoian.cz/LEdoian/birdvisu}, which will also contain any
|
||||||
|
future improvements.
|
||||||
|
|
||||||
|
The only strict dependency of Birdvisu is Python3.10 or newer. While the project
|
||||||
|
depends on the PySide6 library for the user interface, it can be downloaded
|
||||||
|
as a wheel from PyPI. Of course, using a system-wide installation of
|
||||||
|
PySide6 is also possible.
|
||||||
|
|
||||||
|
Birdvisu can read the topology information from files, so it is not necessary
|
||||||
|
to have a BIRD running and configured if only showing static data is required.
|
||||||
|
|
||||||
|
We only support running the project on Linux. However, Birdvisu might be able
|
||||||
|
to run on other types of operating systems, since we have only used
|
||||||
|
cross-platform libraries.
|
||||||
|
|
||||||
|
There are several ways to start the program. The recommended method is to
|
||||||
|
install the project into a Python virtual environment and using the \verb|visu|
|
||||||
|
command. Running the \verb|visu.py| script also works when PySide6 is installed
|
||||||
|
in the system, without requiring the installation step.
|
||||||
|
|
||||||
|
Once the program is started, the user is presented with an empty canvas. Using
|
||||||
|
the \emph{Topology} menu, it is possible to load both a reference and current
|
||||||
|
topologies. Both can be loaded from a file, the current one can also be
|
||||||
|
retrieved directly from a running BIRD via its socket. In the latter case, the
|
||||||
|
user is provided with a dialog to pick an area and OSPF instance.
|
||||||
|
|
||||||
|
Once both topologies are loaded, the graph of the topology appears. Now, the
|
||||||
|
vertices can be moved around to the user's liking. Alternatively, the
|
||||||
|
\emph{Positions} menu provides a way to load the positions of vertices from a file.
|
||||||
|
|
||||||
|
The program expects the topology files to have the \verb|.ospf| extension,
|
||||||
|
positioning files may end in \verb|.visu|. Nevertheless, any files may be used,
|
||||||
|
they just are not offered by default.
|
||||||
|
|
||||||
|
Several highlighting ways are available. In the \emph{Highlight} menu, the user
|
||||||
|
can choose to show differences between the reference and current topology, or
|
||||||
|
set the widths of edges according to their costs. Alternatively, by
|
||||||
|
right-clicking any vertex, it is possible to highlight its shortest path DAG.
|
||||||
|
If the user wants to find a specific route, showing the DAG also serves as
|
||||||
|
selecting the start vertex. The context menus for vertices then allow finding
|
||||||
|
the path to those vertices. Note that stub and external networks are sinks in
|
||||||
|
the OSPF topology, so it is expected that the program draws an empty DAG for them.
|
||||||
|
|
||||||
|
Finally, there is an option to reload the shown graph in the Topology menu. We
|
||||||
|
decided that the graph should not change unexpectedly, because that could be
|
||||||
|
unpleasant to use.
|
||||||
|
|
||||||
|
As a part of Birdvisu we ship the files \verb|gennet.ospf|,
|
||||||
|
\verb|gennet-changed.ospf| and \verb|gennet.visu| for demonstration purposes.
|
||||||
|
These files provide a topology of the default Gennet, the same topology with
|
||||||
|
several manual changes, and a placement of vertices like in figure~\ref{fig:gennet}.
|
||||||
|
|
||||||
|
\iffalse
|
||||||
|
\section{Extending Birdvisu}
|
||||||
|
\fi
|
||||||
|
|||||||
@ -1 +1,88 @@
|
|||||||
\chapter{Evaluation}\label{ch:evaluation}
|
\chapter{Evaluation}\label{ch:evaluation}
|
||||||
|
|
||||||
|
To show that Birdvisu is a usable project, we have tried to use it in several
|
||||||
|
network systems, both synthetic and already deployed. Here we summarise our
|
||||||
|
experience with using it.
|
||||||
|
|
||||||
|
Because our project is mainly an interactive program, we do not present any
|
||||||
|
performance or other measurements. Therefore, we rather focus on the subjective
|
||||||
|
feeling of the project and evaluate the design decision from chapter~\ref{ch:design}.
|
||||||
|
|
||||||
|
\section{Gennet}
|
||||||
|
|
||||||
|
Naturally, Gennet, as described in section~\ref{s:gennet} is supported quite
|
||||||
|
well. Since we had complete control of the whole network, we could test e.g.
|
||||||
|
multi-area OSPF deployment, which is not common in real network systems, as far
|
||||||
|
as we are aware.
|
||||||
|
|
||||||
|
However, only small networks can be simulated in Gennet, because each router
|
||||||
|
requires disk and memory, which may be quite scarce.
|
||||||
|
|
||||||
|
\section{Our home network}
|
||||||
|
|
||||||
|
At home, the author relies on a dynamic routing to switch between falling
|
||||||
|
uplinks and to provide a simple way to address virtual machines across the
|
||||||
|
network system. This was one of the reasons we decided to look for
|
||||||
|
visualisations of OSPF topology state.
|
||||||
|
|
||||||
|
Since it only spans a single room, this system is even smaller than Gennet,
|
||||||
|
containing only three routers and less than 10 networks (the exact number
|
||||||
|
depends on which devices are up at the time). We believe that major issues do
|
||||||
|
not show up at this scale.
|
||||||
|
|
||||||
|
Naturally, Gennet can be connected to the home network. At that point, our
|
||||||
|
approach to laying out vertices starts feeling suboptimal, because edges cross
|
||||||
|
unnecessarily often. The connections are clear, however, and this can be
|
||||||
|
alleviated by using a fixed layout in a file. In the future, this could be
|
||||||
|
addressed by using a force-based approach for the automatic layout.
|
||||||
|
|
||||||
|
\section{Department of Applied Mathematics}
|
||||||
|
|
||||||
|
The department which advised this thesis also uses OSPF in its infrastructure.
|
||||||
|
Again, the main purpose is to address containers and virtual machines in the
|
||||||
|
system. The topology consists of 5 routers and about 27 networks, most of which
|
||||||
|
are stub.
|
||||||
|
|
||||||
|
As in the previous case, the main issue is the automatic vertex layout. Also, since most of the
|
||||||
|
networks are stub (and often only contain a single host), the graph could
|
||||||
|
position these networks near each other, or even collapse them into one vertex.
|
||||||
|
Birdvisu does not unfortunately support this at the moment.
|
||||||
|
|
||||||
|
\section{Czela.net}
|
||||||
|
|
||||||
|
Czela.net~\cite{czelanet} is a network system run by a community of network
|
||||||
|
enthusiasts in Čelákovice and the surrounding area. There are about 1600 people
|
||||||
|
connected to Czela.net. This is the typical OSPF
|
||||||
|
deployment, whose main task is to dynamically provide fallbacks in case of
|
||||||
|
outages. It is also an example of a larger network, with 45 routers, 32 transit
|
||||||
|
networks and 178 external routes\footnote{Most of these would be stub routes in
|
||||||
|
other deployments, but there is little difference from the topology perspective.}.
|
||||||
|
|
||||||
|
Unfortunately, their infrastructure does not use BIRD anywhere and we were not
|
||||||
|
able to connect our instance to any of their transit networks. Therefore we
|
||||||
|
only tested displaying the topology based on a dump from one of their MikroTik
|
||||||
|
routers, which we manually converted to mimic BIRD's format. We believe this
|
||||||
|
should not affect the performance much, because the retrieval of data from BIRD
|
||||||
|
is only occasional and once BIRD dumps the topology, the procedure is the same
|
||||||
|
as with loading the topology from file.
|
||||||
|
|
||||||
|
This turned out to be helpful for both us and Czela.net. We discovered that our
|
||||||
|
method of highlighting of costs does not work well with too big range of the
|
||||||
|
costs, and on the other hand, we found several misconfigurations in their
|
||||||
|
network (some routers had external routes to transit networks, a few networks
|
||||||
|
with routing-unaware clients were used as transit), even without any other
|
||||||
|
knowledge of their system.
|
||||||
|
|
||||||
|
We did not notice any performance issues when dealing with the topology.
|
||||||
|
|
||||||
|
\bigskip
|
||||||
|
|
||||||
|
Unfortunately, we did not have the opportunity to test in a large network (the
|
||||||
|
Czela.net's one is the largest we tested), so we do not really know the limits
|
||||||
|
of Birdvisu. Those are even hard to guess, because while we are trying to
|
||||||
|
use rather fast algorithms, they are implemented in Python, which can sometimes
|
||||||
|
be quite slow, and more importantly, does not support threads well. The heavy
|
||||||
|
use of hash tables and indirection can also impair performance.
|
||||||
|
|
||||||
|
Overall, the testing did not discover any important problems with the design of
|
||||||
|
Birdvisu, we are only aware of issues related to small parts of the project.
|
||||||
|
|||||||
@ -1,2 +1,57 @@
|
|||||||
\chapter*{Conclusion}
|
\chapter*{Conclusion}
|
||||||
\addcontentsline{toc}{chapter}{Conclusion}
|
\addcontentsline{toc}{chapter}{Conclusion}
|
||||||
|
% Hacked figure number?
|
||||||
|
\setcounter{chapter}{6}
|
||||||
|
|
||||||
|
We developed a simple and standalone tool for visualising OSPF topologies. The
|
||||||
|
program is functional and can visualise network systems of medium size. The
|
||||||
|
project's design will allow additional features to be added in the future.
|
||||||
|
|
||||||
|
The project also meets the goals stated in chapter~\ref{ch:motivation}:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Birdvisu utilises BIRD to collect data about the whole network system from a single host,
|
||||||
|
\item the project can be easily run from any Linux machine, not requiring any server-based setup, and
|
||||||
|
\item its topology-centric approach has successfully discovered minor issues with an existing OSPF deployment.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
The only stated goal Birdvisu fails to fulfil at this time is the ability to
|
||||||
|
exchange data with other projects. However, the project's design expects such
|
||||||
|
functionality, so enhancing Birdvisu in this way should be easy in the future.
|
||||||
|
|
||||||
|
\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
|
||||||
|
\textit{Birdvisu} & \yes & \no & \no & \yes & \yes \\
|
||||||
|
\hline\end{tabular}
|
||||||
|
\caption{Comparison of Birdvisu's approach compared to other known approaches. See also table~\ref{t:comparison1}.}
|
||||||
|
\label{t:comparison2}
|
||||||
|
\end{table}
|
||||||
|
\egroup
|
||||||
|
|
||||||
|
\section*{Future work}
|
||||||
|
\addcontentsline{toc}{section}{Future work}
|
||||||
|
|
||||||
|
There are many ways Birdvisu can be expanded in the future. Apart from the
|
||||||
|
stated ones (exports, better vertex placements, \dots), it could be possible to
|
||||||
|
support other routing daemons and even other link-state protocols like Babel.
|
||||||
|
|
||||||
|
Another interesting possible use case could be running Birdvisu headless. When
|
||||||
|
combined with the export feature, this could allow using the project as a data
|
||||||
|
source for other visualisation tools. While this is currently not possible,
|
||||||
|
because the GUI controls all the parts of the program, it might be possible to
|
||||||
|
separate the GUI and the coordination part.
|
||||||
|
|
||||||
|
More Annotators could also be written to provide other functions, like
|
||||||
|
detecting single points of failure. And last, but not least, the user interface
|
||||||
|
can definitely be prettier.
|
||||||
|
|||||||
@ -1,4 +1,31 @@
|
|||||||
\chapter*{Glossary}\label{ch:glossary}
|
\chapter*{Glossary}\label{ch:glossary}
|
||||||
\addcontentsline{toc}{chapter}{Glossary}
|
\addcontentsline{toc}{chapter}{Glossary}
|
||||||
|
|
||||||
\XXX{TODO}
|
% This is hard to format reasonably, so we at least try to do it consistently.
|
||||||
|
|
||||||
|
\strut\indent{}A \emph{bridge} is a networking device, which forwards link-level
|
||||||
|
frames between interfaces.
|
||||||
|
|
||||||
|
The term \emph{community wireless network}
|
||||||
|
describes a system of often wireless networks, which is managed by a community
|
||||||
|
rather than by an ISP.
|
||||||
|
|
||||||
|
\emph{Dual-stack} networks can forward and process both IPv4 and IPv6 packets.
|
||||||
|
|
||||||
|
When a program is run without being able to display graphical elements, it is said to be run \emph{headless}.
|
||||||
|
|
||||||
|
A \emph{homelab} is a small infrastructure, on which a network enthusiast can experiment and thus improve their networking skills.
|
||||||
|
|
||||||
|
\emph{Netsplit} is just a short form for \uv{network split}.
|
||||||
|
|
||||||
|
A \emph{next hop} is the name for the following router a packet is forwarded to.
|
||||||
|
|
||||||
|
In Linux distributions, a \emph{package} is a common way to distribute software.
|
||||||
|
|
||||||
|
\emph{Quad-dotted notation} denotes writing a
|
||||||
|
32-bit number as four decimal numbers representing individual bytes, with dots
|
||||||
|
between them. The numbers are written in the network order, also known as big-endian.
|
||||||
|
|
||||||
|
A \emph{routing daemon} is a program running on a router that exchanges routing information with other routers.
|
||||||
|
|
||||||
|
Python's current way of distributing compiled software is called \emph{wheel}.
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 56 KiB |
@ -0,0 +1 @@
|
|||||||
|
*.pdf
|
||||||
@ -0,0 +1,4 @@
|
|||||||
|
all: dot.pdf neato.pdf circo.pdf sfdp.pdf fdp.pdf twopi.pdf
|
||||||
|
|
||||||
|
%.pdf: source.dot
|
||||||
|
$* -Tpdf -o$@ $<
|
||||||
@ -0,0 +1,16 @@
|
|||||||
|
graph "This is not good" {
|
||||||
|
rou_x -- {net_7 net_6};
|
||||||
|
rou_a -- {net_6 net_4};
|
||||||
|
rou_b -- {net_6 net_5};
|
||||||
|
rou_c -- {net_4 net_2};
|
||||||
|
rou_d -- {net_4 net_3};
|
||||||
|
rou_e -- {net_5 net_2};
|
||||||
|
rou_f -- {net_5 net_3};
|
||||||
|
rou_g -- {net_3 net_1};
|
||||||
|
rou_h -- {net_2 net_1};
|
||||||
|
rou_i -- {net_1};
|
||||||
|
pm -- {internet vl16};
|
||||||
|
qs -- {internet vl16};
|
||||||
|
tr -- {internet vl15 vl16 vl2 vl42};
|
||||||
|
zr -- {net_7 vl101 vl16};
|
||||||
|
}
|
||||||
Loading…
Reference in New Issue