NetworkLabNotes/chapter/layer3.tex

\chapter{Layer 3}

\section{Routed Network}

\subsection{Administrative Distance}

\begin{table}[]
    \centering
    \resizebox{\columnwidth}{!}{%
        \begin{tabular}{|l|l|}
            \hline
            \textbf{Routing Protocol} & \textbf{Administrative distance} \\ \hline
            Directly connected interface & 0 \\ \hline
            Static route out an interface & 1 \\ \hline
            Static route to next-hop address & 1 \\ \hline
            DMNR - Dynamic Mobile Network Routing & 3 \\ \hline
            EIGRP summary route & 5 \\ \hline
            External BGP & 20 \\ \hline
            Internal EIGRP & 90 \\ \hline
            IGRP & 100 \\ \hline
            OSPF & 110 \\ \hline
            IS-IS & 115 \\ \hline
            Routing Information Protocol (RIP) & 120 \\ \hline
            Exterior Gateway Protocol (EGP) & 140 \\ \hline
            On Demand Routing (ODR) & 160 \\ \hline
            External EIGRP & 170 \\ \hline
            Internal BGP & 200 \\ \hline
            Next Hop Resolution Protocol (NHRP) & 250 \\ \hline
            Floating Static Route (ex. DHCP-learned) & 254 \\ \hline
            Unknown (Others) & 255 \\ \hline
        \end{tabular}%
    }
    \caption{Cisco default administrative distances}
    \label{cisco-default-administrative-distances}
\end{table}

Always remember the following points for Cisco devices:\cite{wiki:Administrative_distance}
\begin{itemize}
    \item An administrative distance of 255 will cause the router to remove the route from the routing table and not use it.
    \item Since IOS 12.2, the administrative distance of a static route with an exit interface is 1. Prior to the release of 12.2 it was in fact 0.
    \item Only the interface itself has an administrative distance of 0, since a route cannot have a distance of less than 1.
    \item Directly connected routes have an administrative distance of 0.
\end{itemize}

\newpage

\section{OSPF}

Used in \gls{ip} networks (v4) and a \gls{lsr} protocol. Defined as \gls{ospf2} on \rfc{2328}
from 1998. v1 first published as a \gls{rfc} back in 1989. From closely watching
the development of the \gls{isis} routing protocol. As they were developed in
the \gls{ietf} and the \gls{iso} organizations 
receptively.\cite{Theendle83:online}

\gls{ospf} came from a need of replacing \gls{rip} with something else. Because 
networks got larger and hop-count based metrics was not going to cut it anymore.
So \gls{ospf} was born from closely watching the development of \gls{isis} 
going on at around the same time.

\subsection{Algorithm}

The protocol uses Dijkstra\tsq{s} algorithm when calculating metrics
mathematically.

The exchange of routing updates is done with \gls{ospf} own method. Directly
using \gls{ip} protocol 89 and multicast address 224.0.0.5 for link-local updates and
224.0.0.6 for updates to all designated routers in an \gls{ospf} domain.

\textit{P2P} links just exchange updates to each other.
On \textit{broadcast} segments of the network. The routers present elects a 
designated 
router to handle the exchange of routing information updates. And a backup 
designated router is elected should the primary fail at some point. So as to 
avoid instability in the exchange of updates.

Dijkstra\tsq{s} algorithm. First formulated by computer scientist Edsger W. 
Dijkstra in 1956 and published 1959. Is the formula behind \gls{ospf} path 
calculation.\cite{wiki:Dijkstra's_algorithm}
Every node in the network knows about every path to any given destination in 
the network. And only the best path is then selected for candidate route to be 
used for forwarding traffic.

\subsubsection{Topology}

OSPF is divided into areas hierarchically. With the backbone area being the 
authoritative central area.

\fig{ospf/area-hierarchy}{OSPF Area Hierarchy}{OSPF Area Hierarchy}

All traffic is forced to go by the backbone area when in transit from one area 
to another. This in turn works fine for the most part. But requires strict 
discipline when expanding and/or upgrading the network.
This is even more true when networks merge (fx. company merger/acquisition) 
together. The ugly solution to having areas to far away from the backbone area 
is Virtual links between ABRs across a non-backbone area.

\fig{ospf/virtual-link}{OSPF Virtual Link}{OSPF Virtual Link between abr 
routers across non-backbone area}

\subsubsection{Database}

\subsection{Timers}

By default a 10 second hello timer and 40 second dead timer\footnote{Dead timer should always be 4x the hello timer}

\subsection{Filtering}

\subsection[OSPF vs IS-IS]{OSPF versus IS-IS}

This is a long-standing battle between routing protocols of the 1990s. Compared 
there were quite a number of differences between \gls{ospf} and 
\gls{isis}.\cite{JuniperKatz2000:online}

\begin{itemize}
    \item \gls{ospf} was developed at \gls{ietf}
    \begin{itemize}
        \item Very strictly defined
        \item Optimized hard for \gls{ipv4}
        \item Areas separated by routers
        \item Updates done over \gls{ip}
    \end{itemize}
    \item \gls{isis} in \gls{iso}
    \begin{itemize}
        \item Loosely defined in part because of less interest in development 
        from the \gls{ietf}.
        \item Very extensible. So protocol support can be implemented while 
        only extending the specification.
        \item L1/L2 areas separated on links instead of routers
        \item Updates sent directly on the link instead of being encapsulated 
        in \gls{ip} packets.
    \end{itemize}
\end{itemize}

This is all good and all that. Things have changed since the starting point of 
both protocols being defined in the late 1980s.

\gls{isis} had a stable implementation up through the 1990s and became the 
standard of the era in \gls{isp} networks. Where as \gls{ospf} remained largely 
the standard in medium-large enterprise networks.\cite{JuniperKatz2000:online}

Today in late 2010s. Many of the things that made the difference is being 
considered being largely irrelevant. Both because computing hardware has come a 
long way since and the optimizations implemented in the protocols is defined 
for yesterdays networks of the 1990s. Not the 2010s.

\newpage

\section{IS-IS}

\newpage

\section{EIGRP}

\gls{eigrp} is Cisco's enhanced edition if \gls{igrp}. Dating back to 1993 and a
leg for Cisco over other vendors back in the early days of the Internet. (..
hmm. And remember Cisco's implementation of \gls{ospf} was known to be unstable
until the early 2000's.)

The change to \gls{eigrp} from \gls{igrp} was due to the support of classless
routing. (\gls{igrp} only supported classful routing of class A (/8), B (/16),
and C (/24) networks.)

Cisco converted \gls{eigrp} to an open standard back in 2013 with
\rfc{7868}.\cite{wiki:Enhanced_Interior_Gateway_Routing_Protocol}

\gls{eigrp} adds support for \gls{vlsm} and the \gls{dual} with improved routing
capabilities in comparison to \gls{igrp}. Overall \gls{eigrp} provides better
capabilities compared to it's predecessor.

\subsection[Math]{The Math behind}

\fig{math/eigrp-dual-long}{eigrp-dual-long}{\glspl{eigrp} \gls{dual} full
    formula}

By default $K_2$, and $K_4$ is set to zero. (The are user customizable!) And
$K_5$ is set to 0.

In effect the resulting shorter formula is this:

\fig{math/eigrp-dual-short}{eigrp-dual-short}{\glspl{eigrp} \gls{dual} short
    formula}

\subsection{How it actually works}

\gls{eigrp} does it routing on a \texttt{next-hop} basis. Meaning it only stores
information about a given routes next turn. And \textbf{not} about the
destination itself. (Like \gls{ospf} does)

\subsubsection{Defaults}

\gls{eigrp} runs on Cisco equipment with values of:
\begin{itemize}
    \item \itemhead[]{Administrative Distance (Defaults)}
    \begin{itemize}
        \item Internal: 90
        \item External: 180
        \item Summary: 5
    \end{itemize}
    \item \itemhead[]{Timers}
    \begin{itemize}
        \item Hello: 5s / 60s \footnote{The larger timer value applies at speeds <= T1 circuit bandwidth (a.k.a. lower-than-equal-to 1.544 Mbps)}
        \item Hold: 15s / 180s
    \end{itemize}
    \item \itemhead[]{Supported Protocols}
    \begin{itemize}
        \item \gls{ip}
        \item \gls{ipx}
        \item AppleTalk
    \end{itemize}
    \item \itemhead[]{Other}
    \begin{itemize}
        \item Type: Distance Vector
        \item Algorithm: \gls{dual}
        \item Transport: \gls{ip}/88
        \item Authentication: MD5
        \item Multicast \gls{ipv4}: 224.0.0.10
        \item Multicast \gls{ipv6}: <!-- some number -->
    \end{itemize}
\end{itemize}

\subsubsection{Tables}

\gls{eigrp} contains three tables for storing route information.

\begin{enumerate}
    \item \itemhead[]{Neighbor Table}
    \begin{itemize}
        \item \textit{Lists \textbf{all} directly connected neighbors}
        \item Next-Hop Router(s)
        \item Interface(s)
    \end{itemize}
    \item \itemhead[]{Topology Table}
    \begin{itemize}
        \item \textit{Lists \textbf{all} learned from \textbf{all} \gls{eigrp} neighbors}
        \item Destination
        \item Metric
    \end{itemize}
    \item \itemhead[]{Global Routing Table}
    \begin{itemize}
        \item \textit{Best routes from \gls{eigrp} topology tabel will be copied to the routing table}
    \end{itemize}
\end{enumerate}

\subsection{Stub Routing}

\gls{eigrp} features some different ways to configure routers for specific routing scenarios. \texttt{Stub} routing is one of them.

Stub routing effectively prevents the given stub site/router to be used for transit traffic.

If a router is configured as a \texttt{Stud Router}. It only carries information about \tsq{it}s locally connected routes and a default route back to the transit routers. \tsq{It}s also omitted from being queried about networks is does not advertise. {\small (I.e. The Routes Query Process)}s

\subsection{Updates Exchange}

\begin{enumerate}
    \item Routers always exchange full topology table information when neighbor-ship is established.
    \item Now refresh of data will be done. Unless topology updates occur.
    \item If the topology changes. A partial update about the specific prefix is sent to neighbors.\footnote{Changes includes metric components, link statuses, change in announced topology information.}
    \item If a neighbor-ship fail. Then a new adjacency is formed with a full topology exchange is done.
\end{enumerate}

Always remember \gls{eigrp} does split-horizon by default on all active links when exchanging topology updates.

Split-horizon is the \textit{famous} rule about not sending topology updates back to the router who sent the topology update in the first place.

\gls{eigrp} uses \gls{rtp} to send topology updates and confirmation receipts.

On \gls{p2p} interfaces. \gls{eigrp} simply send and ACK back to the sender.
On multi-access interface/segments. \gls{eigrp} sends updates to 224.0.0.10 and receivers reply with a unicast ACK message to the sender.

\subsection[SIA]{Stuck-in-Active}
\gls{eigrp} is known and feared for it being \texttt{Stuck-in-Active} mode when exchanging route updates between routers. The Stuck-in-Active state could cause problems on low end network gear with a low amount of resources available for the routing process. Which in cases could cause the network device to use all available resources when querying neighbor devices for updates.

\fig{eigrp/stuck-in-active}{stuck-in-active}{EIGRP Stuck in Active}

End result is neighbor ships between \gls{eigrp} routers is terminated and re-established again with a fresh set of route updates going out.

Imagine a large \gls{eigrp} topology (3-digit number of routers) in a single domain and beginning with 1 neighbor-ship gets re-established. And then again and again and again. Can result in quickly several routers going Stuck-in-Active because \gls{eigrp} queries are not getting answered within a short time-frame when all routers needs to query \tsq{it}s own neighbors and their neighbors and their neighbors and so forth. Until their are no more neighbors to be queried up and down the hierarchical network topology.

\fig{network/routing}{network-topology}{Medium sized network topology}

\subsection{Non-Cisco Implementations}

This is always a particular point of discussion around \gls{eigrp}. Cisco has released \textit{some} information on how \gls{eigrp} works.
Not \textit{all} information.
And only as \textit{informational} RFCs.
This ensures Cisco \textit{still} has control of the development of the protocol.
Because they have retained ownership by only publishing informational RFCs.

This has been a hindrance for the adoption of \gls{eigrp} in other vendors than Cisco them-self.

Known adoptions of EIGRP includes:
\begin{itemize}
    \item \gls{frr} targeted release 4\cite{Frr30-4047:online}
    \item Quagga has known works for trying to implement \gls{eigrp}. Still not officially implemented, thou.
\end{itemize}

\subsection{Filtering}

\gls{eigrp} routing updates can of course be filtered in- and outgoing direction on Cisco boxes by using prefix-lists and applying the prefix lists under the \texttt{router eigrp x} process.

\newpage

\section{RIP}

rip is the old routing protocol still existing using nukber-of-hops as the metric to calculate which route to take to the intended destination. This approach can work fine but has a nukber of weaknesses.
1. Scales like shit.
2. Does not take into account if 2 different paths with the same amount of hops has different transfer capacity.
3. Has no concept of load sharing traffic between links if the same amount of hops is present amongst the best paths available.
4. Limited to a miximum of 16 hops between source and destination.

\newpage

\subsection{RIPng}

The version of rip supporting ipv6. different to the standard rip in the ng version is using different multicast addresses to communicate on.

\newpage

\section{Babel}

Babel is built on the principles of 1) \gls{dsdv}, 2) \gls{aodv}, and 3) 
\gls{eigrp} protocols.
Made for hybrid networks\footnote{network contains wired and wireless links} 
and can account for a high level of instability on wireless links.

Babel has been reported to be running stable in unstable wireless networks with 
a level of reliability and fast convergence.

\begin{itemize}
    \item Loop-avoidance protocol,
    \item Uses distributed Bellman-Ford algorithm,
    \item \rfc{6126} in 45 pages, \textit{(28 are normative)}
    \begin{enumerate}
        \item Updates by \rfc{7298} {\scriptsize (The Babel extension 
        mechanism)}, and
        \item \rfc{7557} {\scriptsize (Babel \gls{hmac} Cryptographic 
        Authentication)}.
    \end{enumerate}
    \item Highly extensible protocol,\cite{BabelDoe86:online}
    \item Supports \gls{ip4} and \gls{ip6}.
\end{itemize}

Babel on \underline{wired} networks uses by default hop-count. Can be 
configured to include several values when computing the metrics.
On \underline{wireless} networks Babel should be configured to take into 
account factors such as link latency, packet loss, hop-count, and radio 
diversity.

\subsection{Protocol support}

Currently the following projects include support for Babel: 
\cite{Babel-al30:online}

\begin{itemize}
    \item Bird {\footnotesize \url{http://bird.network.cz/}}
    \item FRR {\footnotesize \url{https://frrouting.org/}}
    \item Pybabel {\footnotesize \url{https://github.com/fingon/pybabel/}}
    \item Sbabeld {\footnotesize \url{http://github.com/jech/sbabeld/}}
\end{itemize}

\newpage

\section{Static}

\newpage

\section{BGP}

\wikicommons{BGP_FSM}

The protocol of the internet used since 1994.\cite{wiki:Border_Gateway_Protocol}
Currently based upon \rfc{4271} with updates following in \rfc{6286} \rfc{6608}, \rfc{6793}, \rfc{7606}, \rfc{7607}, \rfc{7705}.

\subsection{Properties}

\begin{itemize}
    \item Uses tcp/179 as \gls{dst} port
    \item Sends keep-alive message every 1 minute
    \item Keep-alive message is 19 byte long
\end{itemize}

Be ware if sessions are terminated immediately upon trying to establish connection. Try debugging following points.

\begin{itemize}
    \item tcp/179 is not open,
    \item random port 1023> is not open,
    \item incorrect peer-ip,
    \item incorrect peer-as.
\end{itemize}

\subsection{Route exchange}

Exchanging routes between routers is a reliant and tolerant manner is \glspl{bgp} 1-advantage over \gls{ospf}/\gls{isis}/\gls{rip}/\gls{eigrp}.

The sheer tuning and control mechanisms \gls{bgp} can offer is simply astounding. Route-maps is the key and access-lists just one option.

\subsubsection[Route-maps]{Route-maps mechanism}

Route-maps is used to target a select set of routes and either modify/add/remove attributes attached to the select route-set.

\begin{itemize}
    \item Routes can be aggregated between \glspl{as}.
    \item Properties can be changed on the fly by matching
    \begin{enumerate}[label={\alph*)}]
        \item \Gls{bgp} communities,
        \item \Gls{ip} prefix,
        \item \Gls{bgp} as-path, 
    \end{enumerate}
\end{itemize}

An simple example of using route-maps is

\begin{cisco}
ip prefix-list 1 permit 172.16.0.0/16 
ip prefix-list 2 permit 192.168.1.0/24 
!
route-map RED permit 10 
 match ip address prefix-list 1 
 set ip next hop 10.1.1.1
 continue 20              ! Continues to apply rules normally only
                          ! applied to prefix-list 2. To apply to
                          ! prefix-list 1, too.
                          ! Any attributes set in '20' will
                          ! override any set during '10'.
route-map RED permit 20 
 match ip address prefix-list 2 
 set ip next hop 10.2.2.2 ! Last rule overrides previous rules from
                          ! previous '10' rule-set.
\end{cisco}

When rules from a rule-set is chained together as shown above. The last rule will override all previous set values regarding the attribute being applied. In this case \texttt{next-hop} from 'permit 10' is overridden in 'permit 20'.

\subsection[States]{BGP States}

The states is the way \gls{bgp} handles peer/neighbor connection establishing. The \underline{playbook} so to speak.

\begin{enumerate}
    \item Idle: \gls{bgp} while initializing refuses all incoming connections. Will initiate \gls{tcp} connection to peer.
    \item Connect: Waits for \gls{tcp} connection. If \gls{tcp} is established goes to state OpenSent. If \gls{tcp} is \textit{un}successful ConnectRetry timer is started and then goes to Active state.
    \item Active: When ConnectRetry counter reaches 0 goes to state Connect.
    \item OpenSent: Sends \gls{msg} to remote node. Waits for reply \gls{msg} before going to OpenConfirm.
    \item OpenConfirm: Nodes exchange keepalive \glspl{msg} and goes to Established state if successful.
    \item Established: Nodes can now exchange KeepAlive, Updates, and Notification \glspl{msg}.
\end{enumerate}

\subsection[iBGP]{Internal Border Gateway Protocol}

\gls{ibgp} is running \gls{bgp} within the same \gls{as} between routers. Much like running a general \gls{igrp} in the network.

Tradition one has to be fearful of creating \textit{routing loops} in the network. \glspl{bgp} mechanism for this is using either \begin{mylist} \item Full Mesh, or \item \glspl{rr} \end{mylist}.

Problems by running \textit{Full Mesh} is the formula of \[ iBGPsessions = n*(n-1)/2 \] \note{where $ n $ is the number \gls{ibgp} speakers} which results in scaling problems as \gls{ibgp} speakers are added to the \gls{as}.

\textit{\glspl{rr}} solves this problem by peering with all \gls{ibgp} speakers in the \gls{as}. All \gls{ibgp} speakers are then clients of the \glspl{rr}. This in turn helps maintainability by also advertising routes learnt from \gls{ibgp} clients to clients. Classic filtering/mathing route-maps/prefix-filters can be used to \textit{not} advertise all routes select group of clients from the \glspl{rr}.

\subsection[eBGP]{External Border Gateway Protocol}

\gls{ebgp} connections is inherently different from \gls{ibgp} connections. Some assumptions are made such as
\begin{enumerate}
    \item a \gls{ttl} of 1 is the default\footnote{Multi-hop \gls{ebgp} can thou be configured and therefore increase the max-\gls{ttl} value},
    \item distance is set to 20 compared to 200 for \gls{ibgp} routes,
    \item Next hop does \textit{not} change for \gls{ebgp} routes advertised to \gls{ibgp} neighbours \textit{by-default}\footnote{Often times it is necessary to tell a router to set itself as the next-hop before advertising to \gls{ibgp} neighbours}.
\end{enumerate}