only conclusion missing now?
parent
a5551ebfc8
commit
c54e6059b0
@ -1 +1,83 @@
|
||||
\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 some 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.
|
||||
|
||||
Again, 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 that 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. 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, 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 capabilities. 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.
|
||||
|
||||
|
@ -1,2 +1,10 @@
|
||||
\chapter*{Conclusion}
|
||||
\addcontentsline{toc}{chapter}{Conclusion}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
%Overall, we think that while not perfect, Birdvisu can still be a helpful tool
|
||||
%for network administrators.
|
||||
|
Loading…
Reference in New Issue