Hello! This is Lazarus at telecom.Tech,
where telecom and networking technologies... are simply explained! Today we'll be simply
explaining the iBGP split horizon rule. Now, if you find this video informative, don't forget
to click that thumbs up button. And if you find the content useful, make sure you subscribe
to get updates to newly uploaded videos. Now, what is the BGP split horizon rule? Well,
simply put, it states that an iBGP router must not advertise any route it has learned from
one iBGP peer to another iBGP peer. Now this is a little bit different from the split horizon rule
that we see in distance vector routing protocols like EIGRP or RIP, which simply states that you
must not advertise a route you learned from a neighbor back to that same neighbor. But it's
okay to advertise a route to another neighbor, right? Well, that's not the case for iBGP split
horizon. It says that you must not advertise any routes learned from any iBGP neighbor to any other
iBGP neighbor. Now let's see what that actually looks like. Now in this topology, R1 learns about
the 20.20.20.0/24 network, because it's directly connected. That network is redistributed into
BGP and it's then advertised to R2. R2 must not re-advertise that route to R3 or R4 and it must
also not advertise it back to R1. Now you may wonder, why is this the case? Well, the purpose
of the iBGP split horizon rule is to avoid routing loops as well as to avoid suboptimal routing.
Now one of the prerequisites of deploying iBGP within an autonomous system, is that each iBGP
router within an AS must have a BGP peering with every other iBGP router in that autonomous
system. Now this is known as the full mesh peering arrangement for iBGP within an AS. Now I
have a video about that requirement that may be useful for you to review. You can find a link to
that video in the description below. Now the split horizon rule for iBGP stems from the full mesh
iBGP peering prerequisite. Now in this topology, we have six iBGP peerings. Now R1 is advertising
the 20.20.20.0/24 network to all other routers within the AS, because it has that iBGP peering
with all the routers in the autonomous system. Now this advertisement does not violate the split
horizon rule because R1 did not originally learn about this network from another iBGP peer.
It learned about it because that network is directly connected and it was redistributed into
iBGP. So R2 learns about this network. Now let's say that R2 violates the split horizon rule
and re-advertises this network to all of its iBGP peers. That means that R4 is now informed
that the 20.20.20.0/24 network is reachable via either R2 or R1. The path via R2 is considered
suboptimal. Now if we extend this example fully then all routers in this AS will advertise this
network to each other via their full mesh iBGP peerings. As a result, it will appear that this
route is reachable via all other routers in the AS. As we have seen, this can result in suboptimal
routing, but it can also result in routing loops. So why is the iBGP split horizon rule necessary?
This rule will not only eliminate iBGP routing and suboptimal routing, but it also ensures that
each router has received information about a route only from the iBGP peer which is that route's
source. So in this scenario, R1 that has injected the 20.20.20.0/24 route into the iBGP domain, is
the only router that can advertise that route. Therefore, all other routers should learn about
that route only from the source of the route, and R1 is that route's source. Now if we increase the
size of the AS to 10 routers, and we assume that there is a full mesh iBGP peering set up in this
AS, and if the split horizon rule is not applied, then every router will learn that
every other router is a possible next hop for the 20.20.20.0/24 network, and you can
immediately see how chaotic such a setup would be, and how pointless that information would be.
Now the iBGP split horizon rule in routers of virtually all vendors including Cisco is
automatically operational. You don't actually have to configure it as it is an inherent part
of the iBGP protocol's definition. However, as with every rule, there are always exceptions.
The split horizon rule works well as long as the full mesh requirement is fulfilled. There are some
situations in which we must violate this rule in order for other functions to operate correctly.
These include route reflectors, confederations, selective route advertisements, as
well as multipath load balancing. When applying route reflectors, we allow certain
routers within the AS, defined as clients, to peer only with the router that's defined as the
route reflector itself, instead of peering with all other routers in the network. The route
reflector receives routing updates from its clients and selectively redistributes
these routes to other client routers, effectively centralizing route management. This
receiving of iBGP routes and re-advertising them to other iBGP routers essentially violates
the split horizon rule. The route reflectors are exempt from this rule as long as the route was
learned from a route reflector client. Now another situation in which the split horizon rule is
violated is when we use BGP confederations. Now, confederations essentially introduce
sub-ASes within an AS. In such a scenario, all the routers within the confederation AS
100, are considered iBGP routers. However, it is possible for one router to re-advertise an
iBGP-learned route to another iBGP router. For example, R1, the source of the 20.20.20.0/24
network, advertises that network to R2. R2, in turn, advertises that network to R3. Both R2
and R3 are in the same AS 100, so such an action violates the split horizon rule. But
because they are in different sub-ASes, the rule is relaxed and is not applied here.
Within each sub-AS, however, the split horizon rule must still be fully enforced. Now, I will be
creating a couple of videos that focus on these two specific features, one on route reflectors
and another on BGP confederations, to understand them more fully and more in depth. So watch out
for those upcoming videos. Now there are a couple more scenarios where the split horizon rule may
be bypassed, including situations where we have selective route advertisements, and multipath
load sharing. Now in certain network designs, it might be necessary to selectively advertise
routes learned via iBGP to other iBGP peers for purposes such as traffic engineering, load
balancing, or implementing specific policy controls. Now this selective advertisement can
sometimes involve bypassing the split horizon rule to ensure that the necessary routes are available
where needed. Similarly, in scenarios where multipath load sharing is implemented, routers
might need to bypass the split horizon rule to advertise multiple paths to the same destination
over iBGP. This allows the utilization of multiple paths for redundancy and load balancing. In both
these cases, we must be careful when we violate the split horizon rule to ensure that we're not
causing routing loops or suboptimal routing, so this should be done very carefully under
controlled conditions. So that's the gist of the iBGP split horizon rule, what it is, why
it's needed, and the circumstances under which it must be relaxed or bypassed. I hope you found
this video useful, and if you have, please click that thumbs-up button. If you'd like me to address
other related topics, feel free to let me know in the comments below, and please subscribe to get
updates to newly published videos. I'm Lazarus at telecom.Tech, I hope you found this video
useful, and I'd like to thank you for watching!