Network Automation using Ansible(BGP Explanation)(Part 3)
iBGP using Route Reflectors
Before we begin the discussion of Ansible Playbooks, we should first take a look at some of the internals of BGP. This will allow us to better understand what we are trying to set up with Ansible . In the first article, we spoke about the famous protocol BGP and how it was used in the Internet. I had already mentioned, we already had basic connectivity between the different routers thanks to OSPF. We are now going to try to set up BGP. When setting up BGP between routers located in the same Autonomous System(AS) we refer to it as internal BGP(iBGP).
So for BGP to function, we first need to specify the BGP neighbors on our routers. What that means is that on R1 we would have to tell it that its BGP neighbors are R2,R3 and R4. If one was to specify all of the neighbors on each router that setup would be called a full mesh or a complete graph in mathematical parlance. This setup would provide us with full connectivity within the AS. Alright, let me show you with an example of where this can become cumbersome:
So consider each of the vertices(1,2,...,8) to be a router. Each edge, between two vertices represents an iBGP connection. Therefore, the total number of required connections required is 28, which is computed through the formula n(n-1)/2 where n=8. This can cause the router to commit a significant amount of its resources into setting up iBGP connections. This configuration doesn't scale well in real scenarios where an AS can contain hundreds of routers.
Therefore, it would be wiser to configure this network using a different approach. I showed the physical topology in the 1st article, but now we will speak about the logical topology. But wait a minute. What is the difference between physical and logical topology? The physical topology of a network refers to how devices are connected with cables. On the other hand, logical refers to how the network behaves and operates. So in our physical setup, we had a square share topology. However, our logical setup resembles a ternary tree:
Instead, we can configure our network using a Route-Reflector(RR) which consists of a RR server and a RR client. The RR clients do not connect to one another instead they only connect to the RR server and send it their routes. In our setup R1 is the RR server and the other 3 other routers act as our RR clients. Assume that R2 sends an iBGP route to R1, R1 reflects that route to the 2 other routers.
Loopback Interfaces for iBGP adjacency
Another important point to understand before we get into the actual playbook configuration is loopback interfaces. Loopback interfaces are virtual/logical interfaces that can be created on a router. Think of them as your loopback interface on your Windows machine that has the IP address of 127.0.0.1. We can set up our iBGP adjacencies using physical interfaces but using loopback interfaces is a much better approach. Unlike, physical ports they cannot go down because of a hardware failure. The only way for them to fail is for the entire router to crash! In which case, you have bigger issues on your hand than a simple interface to fix.
Now our goal will be to setup iBGP using loopback interfaces. We will then have each router create a secondary loopback interface and advertise it into BGP. When I initially configured OSPF, I only advertised the directly connected subnets. So even if I configured the BGP neighbors manually on each router it wouldn't work. Let me explain the problem in more detail using this graph which is also a tree in graph theory:
Let us assume that each vertex(1 to 6) is a router. Now if we want router 1(R1) to set up an iBGP connection to R6 using loopback interfaces we need to tell it how to get there. By default, a router has no routing protocols running. It only knows about networks connected directly to it. So without any routing protocols running R4 only knows about the location of R1,R2,R3 and R5 By advertising their new loopback interfaces with OSPF, the different routers will know how reach those interfaces. In other words, R1 will know where to send those BGP packets in order to set up a connection with R6. This is how I like to look at it: BGP rides over OSPF to find its path.
We will stop here for this article, as we have already covered a lot of material. By now, you should have enough knowledge to understand how our playbook will try to configure this topology. I do not wish to overwhelm you with details. In the next article, we will look at implementing this using a Ansible Playbook.
Reference:
-https://i.stack.imgur.com/MK6Ul.png
-https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Tree_graph.svg/180px-Tree_graph.svg.png
-https://eskipaper.com/images/path-1.jpg