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!