diff --git a/en/chap01.tex b/en/chap01.tex index a65f794..e781386 100644 --- a/en/chap01.tex +++ b/en/chap01.tex @@ -21,8 +21,8 @@ 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 +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 @@ -38,7 +38,7 @@ 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}. +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. @@ -46,8 +46,8 @@ collection are available, so this differentiates them from the previous group. Projects in tis 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 +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 retreive various details from the hosts (Icinga, plotnetcfg). @@ -60,19 +60,19 @@ section~\ref{s:net-split}. 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 +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}. +usually server based with web interface~\cite{nodewatcher-paper}. \subsection{Topolograph} We are aware of the only 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 +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 diff --git a/en/chap02.tex b/en/chap02.tex index 2157a33..00a9c66 100644 --- a/en/chap02.tex +++ b/en/chap02.tex @@ -13,7 +13,7 @@ BIRD routing daemon. \section{OSPF overview} -OSPF\cite{rfc2328,rfc5340} is a link-state routing protocol, which means that routers try to understand +OSPF~\cite{rfc2328,rfc5340} is a link-state routing protocol, which means that routers try to understand the whole topology of the network and find the best path using an algorithm for finding the shortest paths. Usually, Dijkstra's algorithm \X{ref?} is used. OSPF was designed to provide dynamic routing in an entire autonomous system, but @@ -72,7 +72,7 @@ paths to routers and networks in that area, including the external, extra-area and stub networks adjacent to that area. OSPF specifies that the graph has all the networks and routers as vertices, directed edges lead from each router to the incident network with the configured cost and from each transit network to -incident routers with cost 0 (except when the two-part metric\cite{rfc8042} is +incident routers with cost 0 (except when the two-part metric~\cite{rfc8042} is implemented). There are no edges starting at the external, extra-area or stub networks, so that the shortest path DAG calculation does not find paths through them. @@ -82,28 +82,28 @@ specified in the same units as the internal costs, Type 2 cost is larger than any internal or type 1 cost. The OSPF family of routing protocols has undergone long evolution since the -first specification in 1989\cite{rfc1131}, There are currently two versions of +first specification in 1989~\cite{rfc1131}, There are currently two versions of the protocol in use -- versions 2 and 3. While the basic idea is still the same, OSPFv2 can only handle IPv4 systems. Although OSPFv3 claims to be network-protocol-independent, it is usually only used with IPv6 systems and in fact, features like virtual links can only be used with that network -protocol\cite{rfc5838}. +protocol~\cite{rfc5838}. Both OSPF versions have numerous extensions, as can be seen by the number of -RFCs that update the base specifications\cite{rfc2328,rfc5340}. Therefore, we +RFCs that update the base specifications~\cite{rfc2328,rfc5340}. Therefore, we do not implement the protocol ourself, but rather find a suitable routing daemon \X{glos} to determine the current topology. Many improvements of the protocol only affect the topology construction (e.g. -NSSA areas\cite{rfc3101}) or change the data exchange between routers -(Multi-instance extensions\cite{rfc6549}, authentication\cite{rfc5709}, \dots). +NSSA areas~\cite{rfc3101}) or change the data exchange between routers +(Multi-instance extensions~\cite{rfc6549}, authentication~\cite{rfc5709}, \dots). By extracting the topology from a routing daemon, we can support many OSPF extensions for free. For this reason, it is mostly sufficient to only consider the base specifications of OSPF. \section{Routing daemon selection} -While we were mostly determined to use BIRD\cite{bird} from the start, since we already +While we were mostly determined to use BIRD~\cite{bird} from the start, since we already had some experience with it, let us present here a short summary of other possibilities. Note that the particular choice does not affect interoperability with other routers as long as the chosen routing daemon supports extensions @@ -116,14 +116,14 @@ the feasibility would require us to obtain the specific hardware. Therefore, we only consider hardware-independent solutions. While we are aware of several software implementations, many of these do not -seem to be developed anymore (Quagga\cite{quagga}, XORP\cite{xorp}, -OpenOSPFd\cite{openospfd}). Apart from BIRD, we only found FRRouting\cite{frr} +seem to be developed anymore (Quagga~\cite{quagga}, XORP~\cite{xorp}, +OpenOSPFd~\cite{openospfd}). Apart from BIRD, we only found FRRouting~\cite{frr} to be maintained, meaning that it had a release in the past year. While being maintained is not a strict requirement, it would allow us to use that implementation in case OSPF is extended again. However, even BIRD does not implement all the extensions, for example, the -two-part metric\cite{rfc8042}. +two-part metric~\cite{rfc8042}. \section{BIRD interface} @@ -135,7 +135,7 @@ users, so a rather simple client, \texttt{birdc}, is provided in the BIRD's package\X{glos?}. While there is a note of a machine-readable protocol in the -\texttt{doc/roadmap.md} file in BIRD's source code\cite{bird-src}, it is not +\texttt{doc/roadmap.md} file in BIRD's source code~\cite{bird-src}, it is not implemented, so we will need to interface using the socket. This has following consequences, most of which are not very pleasant: @@ -222,7 +222,7 @@ area 0.0.0.1 The tree as output by BIRD\footnote{The format was determined by experimentation and inspecting of \texttt{proto/ospf/ospf.c} in BIRD's source -code\cite{bird-src}.} has three levels, we call them top-level, level-2 +code~\cite{bird-src}.} has three levels, we call them top-level, level-2 and level-3. The top level only contains directives of form \texttt{area AreaID}, with the AreaID being written in the quad-dotted notation. @@ -285,7 +285,7 @@ of scripts called Gennet. Sice it was mainly written to aid Birdvisu, we provide it as attachment~\ref{att:gennet} of this thesis. Gennet is a network generator. Using a hard-coded configuration and a set of -Jinja2\cite{jinja2} templates, it provides a semi-automatic way of +Jinja2~\cite{jinja2} templates, it provides a semi-automatic way of creating several virtual machines (their disk images and startup scripts) and configuration to connect them using software bridges\X{term?}. This will allow changing the state from the host operating system, simulating various network @@ -444,7 +444,7 @@ very creative, there are some limits to such creativity. The largest system which can be spanned by a single OSPF instance is the whole autonomous system (AS). The largest ASes only have about several hundred -thousand routers\cite{as-topologies}. The average degree also seems to be rather +thousand routers~\cite{as-topologies}. The average degree also seems to be rather low. We can derive another limit from IPv4 address allocations. A /8 block (i.e. diff --git a/en/chap03.tex b/en/chap03.tex index 72f040b..f256574 100644 --- a/en/chap03.tex +++ b/en/chap03.tex @@ -335,7 +335,7 @@ neighbours and so on. When there is a completely unplaced component, we place one of its vertices at random. However, disconnected topologies are of little interest to us. -We tried using Graphviz\cite{graphviz} for laying out the vertices, but we +We tried using Graphviz~\cite{graphviz} for laying out the vertices, but we were not satisfied with its result. To demonstrate, the listing~\ref{lst:graphviz} describes the topology of our home network with Gennet attached. Figure~\ref{fig:graphviz} then shows how each of Graphviz's diff --git a/en/epilog.tex b/en/epilog.tex index 001a433..78d786b 100644 --- a/en/epilog.tex +++ b/en/epilog.tex @@ -1,5 +1,7 @@ \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 diff --git a/en/intro.tex b/en/intro.tex index 000aeac..0f8cbc5 100644 --- a/en/intro.tex +++ b/en/intro.tex @@ -74,7 +74,7 @@ particular class in text, it is only capitalised, as in \uv{The keys of the dictionary are VertexIDs}. For network diagrams, we use the Network topology icons from -Cisco\cite{cisco-icons}. The basic icons are shown on +Cisco~\cite{cisco-icons}. The basic icons are shown on Figure~\ref{fig:basic-icons}. \begin{figure}[h] diff --git a/img/gennet.pdf b/img/gennet.pdf index 6438f5f..091a17b 100644 Binary files a/img/gennet.pdf and b/img/gennet.pdf differ diff --git a/img/gennet.svg b/img/gennet.svg index 0ca9cb6..4c7ffd4 100644 --- a/img/gennet.svg +++ b/img/gennet.svg @@ -25,14 +25,14 @@ inkscape:document-units="mm" showgrid="false" inkscape:zoom="1.1893044" - inkscape:cx="338.01271" - inkscape:cy="224.92139" + inkscape:cx="326.24112" + inkscape:cy="225.76222" inkscape:window-width="1920" inkscape:window-height="1167" inkscape:window-x="1024" inkscape:window-y="1094" inkscape:window-maximized="1" - inkscape:current-layer="svg5" />BF