32. BGP Basic Lab iBGP vs eBGP
Now we have to perform the lab related to BGP. Here you can see in the diagram that I have router one in block A, which is 100. So Ace is 100, and A is 200. Route 1 and switch 105 will form an EBGP relationship, with switch 200 in the middle. For example, suppose you switch 10-1 and 10-5; they will form an IBGP relationship. Okay, so let’s start the configuration for R one.If I go to Rwanda, I can go, and I can initiate the router BGP process. For example, who is your next-door neighbor? I can go and check on the directly connected neighbor. So this one, 1105, is a directly connected neighbor. As a result, he has the neighbour number 10105. And then what is the remote for the ACE? So we should go and give the remote to Ace. Say, for example, 200. I’m going to configure Then, if I go to show IPGPsummary, you can see that the state is idle, correct? So it has been initiated. And if I go and do some debugging of IPBGP, what types of packets do I want to debug? So, for example, I don’t want all, but if I can give events and monitor, I can see some of the messages. So already we are monitoring the screen and showing some of the events. If we debug IPGP, I just want to see the TCP number. So, all address families and IPV4 imports to keep it alive, don’t want that out, and so on. Okay, if I do all of them, the output will be substantial. Okay, now there is one other command we have. So you can see that at least I am receiving this message. Active transitioned from active to idle. It’s tried to move from idle to active, but it has not. And then here, you can see that you have a TCB. So if you go and check “show TCP TCB” and then enter “show TCP,” And if you want to see the brief, you just want to see the open ports if you have them, or if you have any other option related to that. So we have the TCP/TCB. That is the commandptcb that is the command. And if you know the TCB address, that will work anyway. So let’s move on and go to the other side. Here I want to initiate the router BGP process 200, and then the neighbour is nine, one, whose remote is 100. That’s it. So, if I go here and we see the packet here, you can see that we should stop the screen. So you can see that you have the open capabilities enabled, routed first, and then enabled again.
Active proceeded to open, sendtoopen, and confirm these transactions. We have actually checked into our session. Then you notice the neighbour is up. Now, go ahead and check the TCP/TCB. So now you have this established session and you have the address as well. Let me undo this. And now you can see the output for this. You can see that the port number is this. So this is a local port. The foreign port is et me undo So most of the information we are getting from here All right, so now the EBGPrelationship is up and running. Now, according to our diagram, I’d like to establish an IEBGP relationship as well. So I know that neighbor’s address is, say, 10110-110-1101, and that his remote is the same as mine. But since I’m using the neighbour command, which is the loopback address, I want to do the update source loopback zero, and I should make sure. as well as interface loopback zero So, yeah, that’s correct. Now I’ll go to one. So let’s go there and do the configuration for this. First of all, let’s enable the BGP 100 whose neighbor’s remote is the same as I have.Then turn on this update source loopback zero. If you dial 10-3 or 10-5, you’ll only get one message. Show the IP BGP summary that you have two neighbors. Both are up and running. So one is up and running. As you can see here, the “zero prefixes” state is up and running. If everything between 10101 and 10501 is fine and correct, they should form the BGP. but it is not. So let’s quickly check the BGP configuration section (BGP).So here you can see that I am part of 200, and this is also part of 200. So here, you can see that directly. You can see that we should have the correct configuration. This is part of $200. And now you can see that we’re getting some sort of notification message. This has been observed to occur when error notification messages are received. We are getting some malformed constructs. And if you check the summary neighboridol like that, it is coming, it is going back, and let’s change the and we return to ANS.
33. BGP Basic Lab iBGP vs eBGP Continue
Alright, so let’s complete the basic lab. Now, if you go to 10, we can see that the BGP is wrong. So I will go and make the changes. We’ll change this to 200 and all of the other configurations will be correct. All right? Now that we have done that, we can go and check the summary. You can see that this is up and running. Likewise, if you go and check IPGPsummary, that is up and running. All right? So now that we have this, we can check other basic stuff as well. For example that.
34. BGP Neighbor & Synchronization
We are going to continue the lab. In addition, I’ll add a few more topics to the lab section, and we’ll go check the BGP neighbors. Once we enable the BGP, we’ll go and check the PGP neighbor. Plus, we have one concept related to BGP synchronization. What does it mean by “BGP synchronization”? Despite the fact that our labs are not the same, I plan to use the same structure: one device for EBGP and a few devices for IBGP. And we’ve already checked the IBGP and EBGP and how we’re going to construct these BGP tables. Now what is happening is that once we have the neighbour table, it will build the BGP table, and then we will have the routing table.
Correct. But one of the important tables we have is the neighbour table. We have this command, “Show IpBGP neighbor,” where we can go and check the BGP neighbour details. If you want to check the specific details for a specific neighbor, then you can go and use this command: show IP BGP neighbour and the neighbour address. Next we have the BGP synchronisation rule. What is happening is that the general rule for BGP, or the golden rule for BGP, is that if your BGP is present inside the autonomous system, you should enable the IBGP rule or perform IBGP full mesh capability within the autonomous system. Suppose if you do not do this, what will happen? For example, in this diagram, this object wants to reach this network. Assume I have an IBGP relationship here; obviously, I have an EBGP relationship here; and obviously, we have an EBGP relationship here. So the traffic or the update will come to B, and then from B, it can go to D. Because remember, in the BGP-IBGP neighbour relationship, it is not mandatory that they have physical connectivity. So this BGP relationship can form over non-connected interfaces as well. Okay? So that means that I can have the IVGP relationship between B and D. It will now proceed to A. At this point, the router C is unaware of this network (10, 50, 5, etc.). If the returning traffic goes and hits D. Assume it again goes to C. Since C does not have the update related to ten50 zero, he doesn’t know how to reach ten50 zero, so he will be working as a black hole. He will start a black hole in the traffic. So what is the rule, then? The rule here is that you should have an EBGP relationship. Sorry, you should have an IBGP relationship among all the devices.
Correct? And that’s the rule you have. This mesh rule, or de topology, should be used. And that’s the reason we are using some sort of other technology, like configuration or route reflection, because if you have so many devices within an autonomous system and if you go and turn on BGP and if you do this full mesh IBGP relationship, then obviously the CPU, the core utilization, and memory utilisation will increase. So this is not the optimal design solution. This does not imply that all routers will achieve this goal because they will have to think more because they will be processing a greater number of control packets. Here is what we can do for VGP synchronization. The local is not a public transportation system. So, if yours is transit or all routers in the transit run IBGP and are fully meshed, you don’t need it. So, when do you not need the synchronisation rule? The answer is when your AC is not functioning as a transit. Second, the IVGPR rule is in effect while all devices are in transit. how you can disable the synchronization. The command is no synchronization, and you can see that twelve-point, 28-bit synchronisation is disabled by default. So in the latest code, this synchronisation rule is disabled. All right, so let’s just stop here, and we’ll go back to our lab section and whatever small and basic verification commands are there. First of all, we’ll check that before moving further.
35. BGP Neighbor & Synchronization Lab
Now we are going to perform the lab task. You can see in the diagram that we have 100, we have 200 inside a S 200, and in between are 102 devices that are going to form the IBGP relationship and the EBGP relationship. So let me quickly log into the devices. We are going to perform some of the tasks that we have covered already in the theoretical section.
So, let me quickly show you what configuration I have on these devices, and obviously, let’s look at the IP addresses as well. So, if I send this script, you can see that we have this IP over switch 10. Let me show you this diagram as well. So, as shown in the diagram, the IP schemarouter one inside is 100, with loopback one, and all the switches have loopback as their name. So, for example, there you can see the loopback IP, then the interface IP, then the interface IP. All right? So you can refer to the diagram that we have, and as for our diagram, we have assigned the IP addresses to the interfaces. Alright, now the next thing that we should do is go and check the BGP neighbor. So I can go check the showIpbgp summary on all devices. Now here, I can see that, as per the hourdiagram, we have the EvGP relationship and the IBGP relationship. If you have this type of topology, it’s still what you want: switch 10 3 and 10 5. Although they are not directly connected, they are indirectly connected and should form a neighbourly relationship. In that case, only they have the full mesh. Even if I don’t have a back-to-back connection here, I can still form a neighbour relationship between the 10/3 and 10/5 because we have EIGRP running underneath. So before doing that, you can see here that all the devices have their EBGP and IBGP relationships running on EvGP in between R1 and 10 five.As a result, the 1051 interface has an Evgp relationship, while the other has an Ivgb relationship. Suppose you want to know details about that particular neighbor. So what we can do is you can go and check “show IP BGP neighbor.” And first of all, let’s see that in this neighbour command, I can see what outputs you have.
So you can go and simply check “Show IP BGP neighbor.” Obviously, it will show you all the neighbors. So here is the neighbour ID for this belonging to 100 as an autonomous system, the router ID, the establishment, what time the neighbour got established, and what type of messages they have exchanged. Here you can check for open notification updates, stay alive, and keep your route fresh. So like that, we can get the details. Now if I am very specific about a certain neighbor, then I can go and run the neighbour command related to that particular neighbor. So I have one neighbour out of ten, and I can run and verify that. Okay, so first and foremost, I’ll demonstrate how we can form the IBGP relationship between 10 5 and 10 3. So let’s do that. I’m already inside building 10 five.I can go here and route to BGP 200. I have a neighbour at, say, 10-3, who has the same remote. Then for this neighbor, I can go and use update source loopback zero. I’ll return to the terminal and run the same command. The neighbour is 10 510-510-5105, the remote is the same, and the neighbour update source is loopback zero. Alright. So we can see here in the IPGP summary that we have one new neighbour added. So not only my directly connected neighbor, but also my indirectly connected neighbor, is there. That is the true power of BGP because it functions as an overlay protocol. Okay, so once we have all of this information, I’d like to say, for example, that in routers 1 and 10, if you go to router 10 and want to put the password, say neighbor, and you can give the password to Cisco. So, if you put the password from one side to the other, check the password route to BCP 100. Just to show you how long it will take, we know that keep alive sends every 60 seconds and the hold down timer is 180 seconds. So it will take some time to tear down the neighbourly relationship. Still, your neighbour is up and running because BGP is meant to be a slow protocol due to various reasons. So if you wait, it will take some time because your neighbour has the password on one side and we don’t on the other.
So I’ll wait until the timer runs out before returning here to set the password. Meanwhile, we’ll go and check the other option. So we have a timer option as well. For example, I can go here to the router process, and then I can check the timers for VGP timers in BGP and then keep them alive. I can give 30 and then hold on. Assume I am 10 and 30 and live a 10-year life. If I give 30, it means that it is true for all of my neighbors. If you are more specific and want to change the timer for a specific neighbor, for example, 10 510-510-5105, you can do so as well. So we can check the timers here and see how many options we have, for example, 20 and 60. As a result, it is telling that you should go and specify the length of your life, say 20 years, and the hold on is 60 years as a peer group. So then it will take that command. We can check later on about the peer group as well. So we can leave it. However, we have the option of specifying per neighbour as well. Okay, so let’s quickly see this BGP configuration. So I have the neighbour with a timer, and if I go ahead and check, and we can go ahead and check, it shows IPBGP neighbour ten one one. So here you can see that you have the neighbor’s established time. It is showing. It displays the hold timer and the keep alive. However, who is my neighbour if you go here and check showIP BGPNever 10 5? That’s ten, ten five. And you can see that there is still this because perhaps the command that we have run is okay, so you can see the timers and the neighbour command when we are running this neighbour command earlier.
So let me show that we are getting some errors because that was not my neighbor. So that was the reason it was throwing an error, right? Because my actual neighbour is what I’ll do now, I can go ahead and do this neighbor, and then I can specify ten and twenty, and that’s it. All right, we’ll go here as well. And I can go here. The router BGP 200 neighbour is ten one one, the timers are 1030, and we can then check show IP summary, clear IP BGP. I’m clearing the BGP table. And now if we go and check the neighbour table, let’s go and check the summary. You can see that after clearing that, we still have the authentication issue because we haven’t put the password on one side. And you can see that the password problem is still present. So I should go and show this neighbour the password, so I can go ahead and give the password.Cisco, once I do that, you’ll see that it will get converse, and the neighbour will come back up. Now it is up. So we know that in BGP, first of all, it will form the neighbour table, then it will go and form the BGP table, then it will go and form the routing table. Alternatively, those items will be added to the routing table. OK, so let’s stop here, and the next section will discuss more about all these behaviors.
36. BGP Route-Reflector Confederation & Peer-Groups
The following topic is the configuration of BGP router reflectors and DPR groups. Now, what is happening in the case of the IBGP relationship is that whenever IBGP appears, they are getting the update from outside. So they are assuming that all of the neighbors are physically connected or not. They are assumed to be in full mesh. Now if they are in the full mesh, then all the IBGP neighbors will send the update to everyone. Otherwise, there is a chance that router D will receive the update and send it to A. However, A will not send to the other router because they will believe the update will arrive in another way. That is also fully mesh-connected. Now, as we approach IBGP full-mesh behavior or approach in that case, we are using some additional bandwidth and consuming more bandwidth, processing, and cycles. So why? Because we have more BGP neighbors, so the more neighbors you have, the more control packages you’ll send and receive to maintain that BGP state or BGP neighbour tables, so that’s one of the things we can do with route reflector. So the idea is that any of the routers present are acting as symmetrical devices, but what does that mean? A symmetrical device is approachable or reachable by the majority of the other routers.
So we’re making that particular device as a route reflector. So when he gets the update, now his responsibility is to give the update to all the other devices, and this approach has actually been taken inside software-defined networking as well. So, if you look into software-defined networking, You will find that we have a cross-architecture: we have a spine, a leaf, and, supposing you have more spines, a spine one and a spine two, so all the leaves are assumed to be connected with the spine. So what does it mean? It means that behind the scenes, all these spines are working as route reflectors, so at the moment they are getting the update. Now it’s their responsibility to send the update to all the lifts. That’s the fundamental here in the route he will get the updates.Suppose I make him a router reflector now, and his responsibility is to send the update to all the other Ivgp neighbors, rather than having the full mesh topology; a route reflector will reduce the number of codes, IBGP, and dramatically increase CPU and memory performance, correct? Not only is the route reflector a technique, but there are others, as we will see in the next slide. So you can see how you can do this here. I I can go to router 1, and I can tell router 1 that your routers b and D are the route reflector clients.
So the configuration is very easy. Simply use the neighbour ID remote neighborID route Reflective Client, and that’s all there is to it. Now we have other approaches as well. We can use BGP configuration to come to the same place or to achieve the same target. Although configuration appears to be a little difficult, But the concept behind this is to reduce the number of IVGAPeers, and inside IVGAP, you can use EBGP-type behavior. So what is happening in this case? You can see in the diagram that you have a main autonomous system. The Evgp relationship will be formed by these main autonomous systems. I have a sub autonomous system within this main autonomous system; who is in charge? And you can think that with regard to the main autonomous system. So he’s the child. He is the child. But now that we have two different autonomous systems, seven, seven, and eight, eight, they will form an EVP type of relationship. So they will send and receive the updates. Because there is no problem with the EvGP relationship. We have this issue only with IBGP relationships inside the autonomous system. Although it is showing only one device, you may have multiple devices inside one is.So they can exchange their neighbouring tables or they can exchange their updates across the autonomous system, right? So that’s one concept you can see: you have different autonomous systems inside the same autonomous system, but what about a S 500? He can only see that A is 300. He will not be able to see inside the autonomous system. And that’s the key here. Now, the configuration is again straightforward, but it’s a little bit tricky.
So, first and foremost, this eight. Eight? is part of 307 seven, which is part of 300 again, so you can see that router’s BGP configuration here. If this is the identifier, then the router configuration is complete. This is a peer, followed by this, and you can see this configuration. If you go and check, you’ll find that inside the configuration, you have to think that these are the EBG PPS, and inside, you have to think that these devices can peer, but they are part of the main group that is 300, so your 807 are part of the identifier 300. Again, you can see that the BGP configuration peer is 77, so for him, he is the peer. This is the configuration for Router B; similarly, if you go and configure Router A, you must follow the same steps, so you can see that step one, step two, and step three. And then this is the same one that we used to use. Correct. Finally, the remote he has is valued at $500. Okay, so these are the steps that we should follow. And you can go ahead and double-check all of these steps. You can refer to the diagram, and then you can have all these steps. As well. So let me quickly return and show you that if you’re here, you can see how difficult EBGP is. It’s part of the configuration group as well. So that’s why you have this last line. Apart from that, you have these four lines. So tricky because he’s part of the main ace, he’s doing the BGP with this ace, and he’s doing the EBGP relationship.
Now, all these commands have been configured here, and you can understand all these steps. The configuration for the outside device will be straightforward and will follow what we discussed previously about the neighbouring and remote areas. That’s it. All right, the final topic for this session is the peer group. You can use the peer group again to improve BGP performance, decrease the number of lines, or optimise processor and memory usage. Suppose I have ten different neighbors, and all of those neighbours have six children that are common. So what commands will be common? So, for example, remote is update, source, route reflector, client; these things are common, and I have ten. For example, I have ten devices. So ten into three means you have 30 configuration lines you can put inside the peer group. So, instead of writing all of these codes, you can go ahead and use neighbour 1, for example, peer group, my group neighbour 2, two, two peer group my group. That’s it. Neighbor 333. That’s it. So you are saving a good amount of code, and apart from that, it effectively optimises the process and the CPU cycles. Okay? All right. So what I’m going to do in the next lab is perform the task related to Route Reflector, and again, we can go ahead and add the peer group as well. We are aware of only a few people who are using configuration in this labor. It is not required that you do the lab or the CLI configuration for configuration, but just for understanding purposes, I have given these notes, and you can refer to them. Okay? Even though it is not required in our CCNP course to do the CLI configuration at least for this section, three or two for Route Reflector, for a future perspective, we should understand at least the route reflection and be a group.
37. BGP Route-Reflector Confederation & Peer-Groups Lab
Now we have the lab related to the router-effective client and the peer group. Here you can see the topology diagram. We have one router, followed by switch 105-10-1103. They are already inside one; we have completed the configuration, such as running IGP as EIGRP in a S 200 and then having an EBGP relationship between an AC 200. So what I do here is make one loop back. You know that we have a loopback here in AS100, and that loopback I will go and advertise. So, for example, I can go to my BGP 100. And we have various methodologies to advertise the network. One of the methods is to use the network command and then give the exact mask. Now, once we advertise this, I can go and verify this inside the peer router. So I can go and check through IP BGP. And here you can see that I am receiving this route. The next hop is one to one. The east path is 100 meters long. Let’s see if you can read the diagram now. So one loopback is coming to this device; this switch is actually 10 five.
Then we’ll see how it gets to 10 1 and 10 3. So using the same command, “show IPGP,” I can go to the BGP table and check to see if it is appearing on the next tab. It will show like this only because the next hops are not getting changed automatically. We must execute a command in order for them to change the next hop. Finally, it’s ten. Again, you can see that the next hop is this. Now, one thing I want to highlight here is that when you go and check the output in 10-5, you can see that you have the asterisk and the greater than sign. This aspect means that it’s valid, and this greater than sign is the best. So it is a valid best route that comes to 10:5. But if we go and check 10, it’s not telling us that this is the best. Even if you go further down the line, if you go to exit 10, it is telling that it’s not the best route. That’s the one thing. The second point to mention is that now that we have established a full IBGP relationship, So if I go ahead and check the show IP BGP summary, we have the relationship with switch 10-5 as well. So, what does it mean if I check the BGP configuration and then remove it, implying that I don’t want the neighbour relationship to form with switch 10-5? Then, obviously, I should go and remove these subsequent lines. Now, if we go and check the BGP, there it is. Now what I can do here is go and clear the BGP since this is a lab, so I can use IPGP star.But be very careful. If you’re running this commodity, there are chances that thousands upon thousands of routes will get refreshed.
So that’s the reason we are using keywords like “soft.” So this is soft reconfig inbound and outbound, and for inbound or outbound like that, we are using those keywords. All right. So now if I go and check the IP BGP summary, we can see that we have only one neighbor. And if you go and check the show IP BGP table, that’s a BGP table. So let me go and run that command, “show IP BGP.” I want to check the BGP table. Now you can see that this VGP table is gone. Why? because that’s the nature that the BGP has. So the routes are coming to this because they are EBP peers, and he will then advertise to this. But one will not advertise those routes to the other devices. Okay, that’s a loop prevention mechanism we have inside BGP until they have full meshroute reflection, subas, or this configuration. So now what we’ll do is go ahead and make 10 of them as route reflectors. So let’s go and do the configuration for 10 one.All right. So we’ll go to number ten. We’re in Building 10. I can connect to the router BCP 100. Then who is our neighbor? It is 200 for ten. So we have a neighbor. Let’s check on the neighbor. We have this command; we can go and check. So I have 10-3 and 10-5 as my neighbors. So I can go to the neighbor. And then we can go and use it as a route reflection client. So I’d like to make this a route reflection client for both 10-3 and 10-5.
So after 10 and three, I have made it. Now, if I go to 10:3 and check IPBGP, you can see that they are still not learning the route that comes from 10:5. So what I can do is go and make this neighbour a route reflection client. And now if you go here to 2033, that’s the bottom one, you will start getting updates from router number one. So it will be like it is coming from here and then going here. Since he’s the route reflector client, he will reflect the route to 10 three.The same is true. If the routes are coming in this direction, he is getting the routes, and then he will go and reflect the routes to 10 five.So both ways, you’ll find that it is valid. All right. So let’s see this. It takes some time because VGP updates take some time to arrive. Let me quickly see this. Do I have a relationship with number ten? It’s there. I’ll enter clear IPBCP. Because it is now up, it is now showing idle. So I’ve got my table set up. I told you one important thing: whenever we are getting the routes, what is happening in the case of IBGP? So you’ve figured out the route and know who the next stop is. He got the route, and his next hop could be this device. Correct. From where I am getting the route But if you see it, you will find that the next stop is still number one one.That’s the problem we have with the IBGP relationship.
So, in this case, we can go to one and make someone our neighbor. So, who is his next-door neighbor? Before I do that, let me quickly show you this. If all the BGP configuration is correct, I can go to my neighbor. Hey, this is the neighbor, and your next stop is me. So this is your next to last option. Now, if you do this, go to 10 one, and check show IP BGP, you will see that. First of all, I need the best route here. Okay? So you can see that 10 five here. He’s telling 10 that the next stop is me. Hey neighbor. This is my neighbor. Your next stop is me. So, if you go here and check, this should be different. It took some time, but it got changed. Even if you go to page 10 three and get updates, we don’t need this command here to page 10. And if I remove command 200, that is neighbour number ten three. I’m your next-best self. Before pressing Enter, if you go here, enter 2103. Who is the next stop? It is showing. Is it indicating that the next hop is fine? for this point in time, so I can go to 10 and I can delete this. We can clear the routes as well. But ultimately, we can see that the target was achieved. So, even without an IBGP relationship, 10 three can obtain routes from the EVGP from other A’s whose actual areas are $100 using the route reflector client. Great. Now the second thing that we have to do is do the configuration related to the BGP peer group. So if you go in and check the configuration, although I have one command, I have two commands. I have very few lines of configuration here. However, if I go to 10-1 and 10-5 and run section BGP, I have a larger number of configurations to reduce.
So, what are our options? We can create the peer group. I can go to 200. I can be your neighbor. And then we can see the name of the peer group. BGP peer group BPG, for example, says only the name. Then all I have to do is go to the peer group. That’s it. What can we say next, “Hello, neighbor, BPG,” and where is the remote? 200. Actually, I’m making this just for the IBGP relationship. So that’s why I’m using this. I could also go to neighbour BPG update source loopback zero. Then again, I can go and check the other commands. Allow me to quickly check BGP. So I have taken this command: I have taken the update source feedback command. Then I have one more command: route reflector client. So for that also, I can use it. So, neighbor, followed by route reflector client. All right? So once we have these commands, obviously I will go ahead and remove this configuration. This is not required now. So, once I have these, I’ll be able to tell my neighbour that my peer group is BPG. Then your neighbour says 10-5, and you’re in BPG, correct? And if we check the configuration where we are, I believe I will lose this section BDP. Okay, so you can see that I now have the peer group and then the neighbours are mapped to the peer group, correct? Even if I don’t need this command, you suggest I remove it; this is not something that should be handled by a peer group. This is not required to be taken care of by a peer group. Assume that as you add more IBC tables or relationships, only this line will grow. So now you have a template where at least your three configuration lines are constants that will be recalled by all these peer groups, correct? So now I can go ahead and check the Show Run Section BCP box. And I have an IVCP command.
So what can I do here that I can copy and paste? Say, for example, these four lines here. Then there’s my 10-three neighbor. Actually, I don’t want it because we have removed it. And this peer group is a PPG. If you have more peers or deneighbors, you should be able to carry out these commands, correct? Obviously, I can say no to this. Finally, for the labour command that we have with 10, you can go ahead and check to see if Section BGP is running. We can go and check BGPsummary since one is gone section.As you can see, I should have that neighbour command that isn’t visible here. So finally, what I can do is go to neighborsay 10, 110, 110, and 1101, and then the peer group is BPG, and we can check to show run section BPG, that is, BGP. All right, so here you can see that you have the template, and then you’re calling that template with this command, and cover BGP is up and running. So this is how we can do the peer group virtually. This is the way that we can go and do the configuration for the route reflection as well.
38. BGP Best Path Selection
We have a very important topic, “BCP best path selection.” We know that BGP has a long list of attributes, and with the help of these attributes, BGP used to provide the best path. So what are those? Let’s start with those, and then we’ll go through a series of labs where we’ll put all of these attributes, or at least the important pathselection attributes, to the test.
So how is BGP providing the best path selection criteria? The BGP contains multiple routes to the same destination. It compares the routes of the peers, starting with the newest entry and working towards the oldest. Now if you see how it is going to be determined, Assume I have multiple paths to a specific destination and then I check, which means PGP will check criteria A-B-C-D-E in order to provide OK if this criteria is met, so I must take this path. If this criterion is met, I must employ it. If this criterion is met, I must use it in this manner. So this is in order. First of all, it will go and check the highest weight, and then it will go and check the highest local preference. Now the weight and local preference will be in the lab section as well. We have the following lab, and you’ll notice that weight and local preference are at least two of the most commonly used attributes. Now both weight and local preference are dictating the best outbound path. So what we are doing is applying weight and local preference, say, attribute values, in the inward direction. So we are going to apply it to the inward direction. That’s the key, actually. So, where are you going to apply these, and who will he affect?
So we are going to apply it in the inbound direction, and then they are going to dictate the outbound path. So that is the most important thing I want to COVID. Now here you can see the order. So let me go back to local preference. route created locally We know that if the route was created by locals, the next number will be 0, 0, 0. That means it’s a self-originating route, then the “as path.” Now, the metric values path and med are both important. Remember that weight and local preference, which are very similar, are the attributes that are increasingly being used in the production network. So, in terms of the path you know BGP is dealing with or According to the as, BGP is a distance vector protocol. So you believe that one auto-number system has a route for a moment, and if you have to cross more as or hop more numbers around, it is not preferred. So, if I reach certain destinations with three A’s versus one, that means the path I take with one will be preferred. So a shorter IS will be preferred over the origin code in the number. So IGP over E, GP over unknown, then MD. Again, I stated that this path and the lowest medical are very similar. Even if we have a lab, BGP route type EBGP will win over IBGPGP. The oldest route is then preferred. The router ID is then determined by determining which router has the lowest BGP router ID. Then the peer address indicates which router originates from the router with the lowest IP. So, with the exception of weight and local preference, where the criteria are stringent, Meg is the only exception. Then there’s age; everything is either the youngest or the oldest. Correct? All right. As can be seen, weight and local preference are applied inbound, dictating outbound. That’s the key, actually. As a result, these three lines are the key inbound dictating the outbound path, while as and mid are used outbound dictating inbound. So what does it mean? So, at least in the case of MD, and bear with me here. Assume you have an ISP one, an ISP two, and then your local as.
Now, in the case of MD, and as a path if you want to prefer ISP 1 versus ISP 2, So you’ll go ahead and apply either Mg or the as path esprit. That’s the key because you are choosing the outbound. So you have one subnet, XXXX, and you want to prefer either one or two ISPs. You can use these methods. Now when we are going to use the local path, So in that case, when you are going to dictate the outbound path, suppose you have two exits and you want to choose one exit over the second exit.In that case, you’ll use either the either-or or local preference. Obviously, I’ll go and clarify these terms, and in the upcoming lab we are going to check the scenarios as well. So here you can see that you have one situation, one scenario, and one route. So, for example, 192 one 10 is received by router D as well as router B. What I want now is for that route to come or be preferred via router B. In that case, we can go to router A, give the neighbour command, and then give the weight command. That’s the only way. The other nice way is that we can go and use the route map. So we can either create an ACL, a prefix list, or an access list.
And then we can create the route map, we can match the prefix list, we can set the weight, and then we can go and apply it to the neighbor. So here, you can see the direction. The directions are in for the outbound traffic. Correct? So to reach this network, I have applied weight to my neighbour and that neighbor. So that means router A will prefer route B to get these routes correct. You have the local preference for the same thing once more. Only the way that we are going to do the coding will change. And you can see that we are going to apply it here. Now, local preferences differ slightly in terms of weight. What is that difference? Local preference, unlike the weight attribute, is passed on to IBGP peers and sent along with updates. If multiple paths overlap, the IBGP router uses local preferences to determine how to exit the ACE. So now what we can do is give local preference—even I can go and apply to these guys. So suppose local preference here is 200, and if I put local preference 100 here, obviously this path will be preferred, right? So that’s the use of local preference. And here you can see that we have an example, but it will check the routemap way of applying the local preference.
As you can see here, the direction is inbound. So we’re at router D, or maybe there’s no problem at router B. So what we’re doing for routers B and D shows that lower is better. So here, if B is 203, obviously the traffic will come via this B because the local preference is 200. Likewise, as you can see here in the policy, we can create the policy for B and D as well in the upcoming laps section. So I have this route, just as we created and applied the route map. I’m matching this, and then I’m setting the local preference, say 300, and then I’m applying in.So that’s number one; number two is my neighbor. Then I’m going to use N. Likewise, I will apply a local preference of 200 to router B. Clearly, router B will be preferred. So as you can see, there’s a difference between weight and local preference. The local preference is passed on to IBGP peers when sending the updates. That is the primary reason you will not find yourself using weight more and more. because anyway, the weight is Cisco propriety as well. Generally speaking, this is the case with local preference. The same thing we can do with weight and local preference to better use local preference is in the lab section. So we have a lab section in the upcoming session. I will go and perform this task of waiting and then local preference, and we’ll see how we are applying the inbound rule to affect the outbound traffic, correct? Yes. Alright, so let’s stop here. We’ll start the lab now.
