diff --git a/en/chap01.tex b/en/chap01.tex index 901ead0..d9c9fa8 100644 --- a/en/chap01.tex +++ b/en/chap01.tex @@ -32,7 +32,7 @@ aware of any collectors of OSPF state data. Various software packages can collect and graph utilisation of network links. This often provides information about link state, but requires collection of data on all hosts. Also, in some cases, this might not provide accurate data of -the system state, as we will see in section~\ref{s:net-broken}. +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. @@ -52,7 +52,7 @@ checking reachability (CaLStats) to being able to retreive various details from the hosts (Icinga, plotnetcfg). This approach can also miss some issues with the system, as described in the -section~\ref{s:net-broken}. +section~\ref{s:net-split}. \subsection{Integrated system management platforms} diff --git a/en/chap02.tex b/en/chap02.tex index db8b2bd..9166255 100644 --- a/en/chap02.tex +++ b/en/chap02.tex @@ -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} diff --git a/en/macros.tex b/en/macros.tex index a465f92..3a7ebe7 100644 --- a/en/macros.tex +++ b/en/macros.tex @@ -46,6 +46,8 @@ \newtheorem*{rem}{Remark} \newtheorem*{example}{Example} + +\newcommand{\cons}{\textit{Consequence:}\/ } %%% An environment for proofs \newenvironment{myproof}{