|
|
|
|
@ -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.
|
|
|
|
|
|
