@ -252,7 +252,7 @@ listing~\ref{lst:ospfnet}.
distance 10
router 198.51.100.1
router 198.51.100.2
address 2001:db0 :b00:7::/64
address 2001:db8 :b00:7::/64
\end { lstlisting}
One of the nice properties of BIRD's output is that whenever there is a level-3
@ -317,7 +317,8 @@ of the network. Routers are assigned router IDs of 172.23.100.$r$, where $r$ is
the lexicographic order of that router (A gets a 1, B is 2, \dots , I becomes
9, X is 10). The IP addresses of the routers have the same number in the last
octet (e.g., the IPv6 of router X in network 6 is fdce:73a4:b00:6::a), and all
routers have an IP address in each incident network.
routers have an IP address in each incident network. The costs of all links are
10 by default.
\section { Unusual network states} \label { s:net-unusual}
@ -326,8 +327,96 @@ Now that we have basic understanding of BIRD and a network system for testing,
we see how both versions of OSPF react to various unusual conditions in the
system.
\XXX { netsplit, multi links w/ same and diff costs, v2 vs v3, mixed segments,
multiple prefixes. napsat na kolejích s gennetem..}
We focus on behaviour of BIRD in following scenarios:
\begin { itemize}
\item Network split: Hosts in the same network stop being able to
communicate with some other host in the same network. This is often
caused by a broken cable or switch malfunction.
\item Multiple links to same networks: It might make sense to connect a
single router to the same network using multiple links, possibly with
different costs. This provides redundancy and helps e.g. avoid network
splits.
\item Network with multiple addresses: Sometimes, a network may have more
than one address (prefix). This may be either intentional or a result of
accidental joining of networks which should be separate.
\end { itemize}
Unfortunately, the behaviour of BIRD in these states is often very different
depending on the version of OSPF.
\subsection { Network splits} \label { s:net-split}
Network splits are of particular interest to administrators. Not only are they
symptoms of a broken part of the infrastructure, but also every netsplit
inherently means that some addresses from the split network can not be reached
by some hosts, because there is no hint, to which segment a packet
should be delivered.
Splits can also be tricky to spot from systems using topology-unaware approaches,
because if a link connecting two switches fails, all ports on hosts are still
up and the traffic in the split network might not change, when no traffic is
routed through the broken link.
When a split occurs, at least one segment stops being able to communicate with
the network's designated router. Either this segment has only one router and
becomes stub, or has more routers and then a new designated router is elected.
(OSPF cannot detect when a network splits and there is no router in a separated
segment. Monitoring of host reachability is therefore still useful.)
The representation of split network in BIRD's output is straightforward: some
routers may become attached to a \texttt { stubnet} , instead of a
\texttt { network} and more level-2 network blocks can appear, one for each
segment that has elected a DR.
For OSPFv3, this forms a valid topology, since the level-3 network directives
are derived from the designated router ID and its interface number, identifying
the network uniquely. However, since OSPFv2 identifies a network using the
shared address in the output, it is not immediately obvious, which of the
segments the router is connected to. Luckily, this can be deduced from level-2
network blocks, because they provide information both about the segment's DR
and about incident routers.
\cons A network address is not sufficient to identify a network or stubnet. To
do that, we either need to also know a designated router ID, in case of transit
networks, or which router the network is connected to, for stubnets.
\subsection { Multiple links}
BIRD's implementation\footnote { We are not sure whether this is the correct
behaviour} of both versions of OSPF seems to announce two copies of the same
network throughout the area, if the designated router is connected to that
network using multiple links. This is not an issue for routing, because using
any of the copies results in the packet being sent to the right network, but is
an unfortunate behaviour for visualisation. In the OSPFv2 dumps there is no way
to differentiate the two copies, since the DR's interface number is not
exposed, so we can only merge them into one network, solving the problem.
On the other hand, in OSPFv3 the interface number may be the only information
used to differentiate different networks, since the networks do not need to
have any addresses assigned. The only safe way is therefore to visualise both
copies just in case.
(There also seems to be a bug, when OSPFv3 dump does not contain the level-2
block of the multiply-connected router on a neighbouring router. We did not
explain this behaviour, but it does not seem to propagate to other routers nor
affect packet forwarding, so we decided to ignore this peculiarity and debug it
later. A simple workaround is to add another router between the actual network
and Birdvisu, which is always possible by using unnumbered networks.)\label { ss:bug}
\subsection { Multiple addresses in a single network}
In OSPFv3, a single network can be assigned zero or more addresses. Therefore,
from its point of view it is not an unusual state. \cons For OSPFv3, the set of
all addresses must be considered to determine whether the network has changed
or not.
OSPFv2 treats each of the address as a separate network, ignoring other
routers. When this is intended, it should not cause problems, and unintended
merges of networks will not interact. However, we cannot detect this state
across the area, unless there is another change in topology (for example, if
this is caused by a cable connected to a wrong port, the network will probably
be stub).
\section { Area structure}
