parent
c54e6059b0
commit
4916c8f8f1
@ -1,10 +1,54 @@
|
|||||||
\chapter*{Conclusion}
|
\chapter*{Conclusion}
|
||||||
\addcontentsline{toc}{chapter}{Conclusion}
|
\addcontentsline{toc}{chapter}{Conclusion}
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
%Overall, we think that while not perfect, Birdvisu can still be a helpful tool
|
\section*{Future work}
|
||||||
%for network administrators.
|
\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 interresting 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.
|
||||||
|
|
||||||
|
And of course, many more Annotators may be written to provide other functions,
|
||||||
|
like detecting single points of failure.
|
||||||
|
Loading…
Reference in New Issue