Compare commits
21 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 |
|
LEdoian
|
ea67b53df0 | 1 year ago |
@ -1,5 +1,5 @@
|
||||
% Metadata k uložení do PDF, podrobnější popis viz dokumentace balíčku pdfx.
|
||||
|
||||
\Author{Jméno Příjmení}
|
||||
\Title{Název práce}
|
||||
\Author{Pavel Turinský}
|
||||
\Title{Vizualizace topologie OSPF}
|
||||
\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.
|
||||
|
||||
\Author{Name Surname}
|
||||
\Title{Thesis title}
|
||||
\Author{Pavel Turinský}
|
||||
\Title{Visualizing OSPF topology}
|
||||
\Publisher{Charles University}
|
||||
|
||||
@ -1 +1,70 @@
|
||||
\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}
|
||||
|
||||
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}
|
||||
\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}
|
||||
\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