\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
\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.
\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.
\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.
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.
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}.
\gls{bgp} zombies\cite{ietf-idr-bgp-sendholdtimer-00} can occuer for a multitude of reasons. Depending on the implementation. Examples are
\begin{enumerate}
\item Overloaded control plane
\item Unable to send out update/keepalives due to full out queues
\item Stuck TCP session the \gls{bgp} daemon is unaware of (e.g. tcp window size changed to 0)
\end{enumerate}
The consequence of \gls{bgp} sessions not being able to close properly. Can sometimes result in zombie routes. Where the router originating the route. Due to having one or more stuck sessions. Are unable to send out WITHDRAW messages. Thereby other routers think the route is still active. And does not withdraw the route from their own \gls{rib}. Ending up with a \gls{rib} containing STALL routes.
One workaround to get rid of zombie routes is to completely reset your routers \gls{rib}. This can be done by example rebooting network edge routers\cite{Navigati54:online}.
As of writing (Nov 2023) the following known public implementations have implemented the draft,
\begin{enumerate}
\item FRRouting\cite{bgpdimpl26:online}
\item neo-bgp\cite{Whatdoes40:online} (bgp.tools)
\item OpenBGPD\cite{Rebgpdse40:online}
\end{enumerate}
As of writing (Nov 2023) the following known public implementations are working on implementing the draft,
It is unknown when commercial vendors will implement the current internet draft. This will most likely not happen until the draft has been adopted as an official RFC.
