\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.
\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{Tables}
\gls{eigrp} contains three tables for storing route information.
\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
\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.
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}.
\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}.
\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}.
