163 lines
6.9 KiB
TeX
163 lines
6.9 KiB
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}
|
|
|
|
\newpage
|
|
|
|
\section{IS-IS}
|
|
|
|
\newpage
|
|
|
|
\section{EIGRP}
|
|
|
|
\newpage
|
|
|
|
\section{RIP}
|
|
|
|
\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} |