Border Gateway Protocol (BGP): Basic Operations

0:00In this Nugget, you and I are going to take a look at some of the properties that make border gateway protocol just incredibly unique, especially when we compare it to other routing protocols. If you haven't thought about BGP in a while, this Nugget's going to serve as a great review. The very first thing that makes BGP so unique, is what it does for us. It is our only exterior gateway protocol in major use today. So we have our interior gateway protocols, and that would be like OSPF running inside of an autonomous system, but BGP is an EGP, which means that it is going to take prefixes that are inside an autonomous system and send those to other autonomous systems.

0:45This is why BGP is the protocol that makes the internet function. Internet service providers can use BGP in order to move prefix information between other internet service providers. The unique characteristics of BGP don't just stop there, though. One of the things that's amazing about it is, it forms point-to-point peerings with other devices. So there's no such thing as forming a neighborship with a whole bunch of devices on the same segment.

1:16It won't do that. For each of the devices it needs to peer with, it does so on a single peer-to-peer, what we call, BGP peering. BGP is also, an application layer protocol, instead of running at like the network layer of the OSI model. So as an application layer, it does something brilliant. It leverages transmission control protocol for its operations. If you look at EIGRP, for example, they wanted reliability in the communications with the IGRP so they had to build that into the protocol.

1:52One example is, an EIGRP speaker will try and multicast transmissions, and if that's not working out, it will fall back to unicast transmissions, as a way to try and ensure reliability. With border gateway protocol, the engineers said, you know what? We're not going to try and engineer all that into the protocol. We'll just rely on the wonders that are the reliable communications of TCP. It uses TCP port 179 then, in its operations. And allows TCP to take care of the reliability that needs to happen between these peerings.

2:28Now when you look at a typical routing protocol, we know that there is going to be some value that is going to be the metric. For instance, in the case of OSPF, we know the metric is cost, and cost is based directly on one value and that is bandwidth. BGP does not work that way at all. BGP uses attributes-- we call them-- instead of just a single metric, and one of the prime attributes of BGP is called the AS path attribute.

3:00And this is a list of all of the autonomous systems that a prefix has had to transit on its journey to, let's say, your autonomous system. So it's a recording of all of this AS path information. The AS path is so critical to the function of BGP, that the protocol is referred to as a path vector protocol. Not distance vector, but path vector. The AS path is not only used to gauge what would be the best path to a destination-- thus the shorter AS path-- it is also used as a loop prevention mechanism.

3:41When an autonomous system sees its own AS number in the AS path, it gets very concerned that there may be a loop in the communications. Something else that makes BGP incredibly unique, is the fact that when we form peerings inside an autonomous system, these are called internal BGP peerings. And when we are forming a peering between autonomous systems, this is called exterior border gateway protocol.

4:11You might ask, Anthony, why do I care? And why does the protocol care? And that's a valid question. The reason why we distinguish between an IBGP peering and an EBGP peering, is that operational characteristics are going to need to change based on how the peering is done. For example, we said there's this AS path that is recording the autonomous systems that are transited. Clearly, over an EBGP peering, when a prefix is sent from this AS to this AS, this AS must put its autonomous system in the path.

4:46But with IBGP, they're sending the prefix to each other, and they don't want to put their own AS in the path when they hand it off to another device. So the rules are going to change when we're talking IBGP versus EBGP, in order to keep things consistent and error free. And the unique properties of BGP just don't end here. We're going to see, again and again, as we examine these BGP Nuggets, that there is just going to be case after case, where the protocol operates in a very different manner from what we would expect with our IGP brethren.

5:28I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00Many people describe Border Gateway Protocol as an extremely complex protocol, but I don't think that really tells the story. You see, BGP policies and controlling prefix propagation inside of BGP, that can be super complex. But the protocol itself, while unique, is pretty simplistic in its operation. In this Nugget, we're going to take a look at that as we examine the BGP message types. When this router right here wants to begin an eBGP peering with this router right here, it is going to rely on Transmission Control Protocol.

0:35And, of course, we know there's going to be a three-way handshake with TCP in order to start that reliable communication session. What's going to happen then is these devices are going to exchange open messages. The open message contains very important information. The primary ingredient of which is the autonomous system number of the peer. This is going to determine whether it's an eBGP peering or an iBGP peering. When the open messages are exchanged, they'll then start exchanging keepalive messages.

1:10This, of course, is a simple little mechanism to make sure the other device is there, happy, and healthy, so that the peering can remain up. When they have updates to share, it's a simple update message that is transmitted. And if anything goes wrong at any point, they can use a simple notification message in order to tear down the peering as a result of some error that may be happening with BGP. There is a route refresh message type.

1:41This is not in the original standard. So this is in addition. But the great news is most of our major networking vendors support route fresh behavior. And route refreshes allow the neighbors to update, let's say, BGP route information or even update things after a pretty major policy reconfiguration without tearing down the peering or affecting the peering in any big negative way. So they can stay peered up just fine after reconfiguration events.

2:13And most times these reconfiguration events, as I've stated, are going to be because of some policy manipulation that we want to make. Let's bring this discussion to life with some Cisco routers. Here, we're going to have R1 peer with R2. And what we'll do is we'll examine the messaging that is utilized between these two devices during the peering. I'll use that topology that we've been looking at. So R1 will be in AS 65111. And R2 will be in AS 65222.

2:46Because we want to examine the actual packets, we will right-click this link, and we will start a capture on that link utilizing Wireshark. Things aren't very exciting on that serial link right now. It's a bunch of SLART messages. And the Cisco Discovery Protocol is all that is being transmitted between those two devices. But I have a feeling, based on our discussion, things are about to change. Here on the R1 device, I'll enter Global Configuration mode. And I will say router bgp 65111 and hit Carriage Return.

3:21We're now in Router Configuration mode for BGP. And I will set up the peering on this side. I say neighbor. And it's 10.12.12.2, the IP address that's on R2's serial interface. And we use the remote as keyword in order to indicate that the remote AS is at 65222. We hit Carriage Return. We exit. And that's it. We can exit one more level to get back to Privilege mode.

3:51Now let's fire up R2 and do the same thing. So Global Configuration mode, router BGP. This AS, of course, is 65222. And then we are going to specify our neighbor of 10.12.12.1. Our remote AS is 65111. Carriage Return. This time I'll be more precise and say end, and we go all the way back to Privilege mode. Now, look at what just happened. I was hoping this would happen.

4:21We just had a BGP adjacency change. We now have a peering with that device. So our two configuration commands, the two neighbor commands on each device, we did properly. And we have an eBGP relationship built. Let's see what's going on in Wireshark. If we scroll down in Wireshark, I'm thinking we're going to see some TCP messages. And there they are. Those TCP messages are establishing the connection using the reliable Transmission Control Protocol.

4:58And we can see just from the summaries here that 179, port 179, is involved in that handshake. Then we can see the BGP messages. Look at this. We have our open messages that are exchanged between the two devices. They start doing their keepalives. There's an initial exchange of update messages to make sure that their databases are in sync with each other. And when I say their databases are in sync with each other, there's not much to sync.

5:28These devices don't have any prefixes to advertise to each other. So let's fix that, and let's see what happens inside of Wireshark. I'll create a loopback zero interface on R1. And I'll give this an IP address of quad ones with a 24-bit mask. And then we'll go into BGP on this device. And let's see, 65111, and we will advertise that network with the network command.

5:59So it'll be the 1.1.1.0 network with a mask of 24 bits. So notice, the network command in BGP will take care of that advertisement. Let's go back over to Wireshark. And now we should see an update worth examining when it comes to BGP. And there it is right there. And if we look inside the Border Gateway Protocol update message, notice, we have Network Layer Reachability Information.

6:32And there is the prefix that this R1 is advertising to R2. Notice it's called Network Layer Reachability Information, or NLRI. One of the most fascinating things about Border Gateway Protocol is that it was designed to carry whatever information you needed to carry. In our usage, it's carrying IPv4 route prefixes as we can see here. But it could carry other information.

7:05We call this capability multi-protocol BGP. So keep that in mind. This is an extremely flexible protocol. And it can carry more than just IPv4 prefixes. In this Nugget, you and I examined, literally examined, the message types that are used by BGP. We know there's the open message. There's the keepalive message. There's the update message. There's the notification message. Hopefully, we don't deal with that a lot, because it indicates that there's an error.

7:37And then there also the route refresh message, which was added for additional functionality. I hope you found this Nugget informative. And I'd like to thank you for viewing.

0:00In this Nugget, you and I are going to learn even more about the operational characteristics of border gateway protocol, by taking our BGP message types. And we remember, that's the open, update, notification, keepalive messages. And we're going to put those under the microscope by seeing the fields inside them. Each message type is going to have a BGP header, of course. And the header information has this pretty darn big marker field. You would think this is hugely important.

0:31It's 16 octets, this field. But it turns out, that this is just going to be filled with all ones. That's because the use of this marker field has been deprecated in the standards. The original idea for this field, was that it could be used to detect like a loss of synchronization between two peers, and it was also thought, that this would be the area in which authentication information could be held. But as I said, it is no longer used for any of those purposes.

1:02It's filled with all those ones, and it's still there, of course, in case there needed to be backward support with some really old BGP device, that expects to see this marker information. So the important fields here in the header, are going to be length-- which is the length of the overall message-- and then, the type field. The type field indicates what type of BGP message we're dealing with. If you see a one in here, you're dealing with an open. A two, would indicate an update.

1:33A three, would indicate a notification. A value of four, would be a keepalive. And then, a five would be that optional route refresh behavior. Note, that there will then be data, perhaps. Now what do you mean by, perhaps? Well data won't follow this header in the case of a keepalive. A keepalive is going to be a message type that we'll look at, and that message format says that there won't be any data with the keepalive message. Now I'm sure you recall, when your system wants to form a BGP peering with another device, it's going to send an open message.

2:10And when we look at the open message format, we note that there is a version number-- whoa, I've got the wrong pen. Let me grab the right pen here. There we go. So there's a version number. So we expect future versions of BGP, and that's how you could indicate the version of BGP that you're using. Your system is also going to send it's AS number in the open message-- this is critical, of course, for that IBGP verse EBGP type behavior. There's a hold time value, and what's interesting about the hold time is you're going to have your hold time in this field, and when the person that you want to peer with receives this, it will look at that hold time, look at its own configured hold time, and then, use the smaller of the two values.

2:57The hold time-- by the way-- needs to be either zero or at least, three seconds. So you can negate hold time with the zero value, but if you're going to set hold time, it needs to be three seconds or greater. Then there's your BGP identifier. This is your BGP router ID, and this is a critical value that's going to distinguish your system uniquely, in the BGP peering. Then, we finally have optional parameters that could be set with the open message.

3:29There's an optional parameter length and then, the parameters themselves, to give us added flexibility with the protocol. Another really important message that we have is the BGP update message, and when we look inside this message, we see that there's going to be an indicator for withdrawn routes length. So the update message is a great way that one BGP speaker can make sure that routes are withdrawn from the BGP table of its neighbor. And that list of withdrawn routes can be in the update message.

4:02Notice then, when we are telling someone about an update-- an additional prefix-- we're going to be making sure that we specify the attributes that go with that prefix. A well-known attribute that we have already mentioned is AS path, that list of paths that the prefix has transited on its way throughout the BGP infrastructure. So AS path would be an example of an attribute. There can be many attributes that we are utilizing, thus, we need to specify the length in the update message.

4:38And then, the attribute information. And then, finally, in the update message, of course-- and we saw this within Wireshark-- we need to see the network layer reachability information. And as we indicated, the great thing about NLRI, instead of this field just being designed for an IPv4 prefix, is that it gives us flexibility. BGP is built to start immediately running things like IPv6 for us. Or VPN IPv4 prefixes inside of something like an MPLS VPN.

5:15We can't forget about our little friend, the keepalive message in BGP, and notice, I've just drawn for us here, the header itself. Because remember, the BGP keepalive is going to a BGP message that just has the header information in it, no data. And then finally, we have our BGP notification message. And we sure hope we don't have a lot of these, but notice, there's an error code. And then, there's an error sub code, to give us a general type of error and then, even more information.

5:47Let me give you an example. If in the error code, we have a value of three and then, in the error sub code, we have a value of three, this would indicate that there is an update message error. That's what this three would indicate so there's a problem with the update message. And then, this would indicate-- this three value-- would indicate that there is a missing well-known attribute. So there's an attribute, like AS path, that we absolutely have to have, and it is not inside of that update message.

6:20This would be a massive error for us in the BGP infrastructure, and the peering would tear down. Studying exactly what's in our message types for our protocols, leads to a richer, deeper understanding of just how the protocol operates, and I hope you've seen that with this look at the BGP message formats. I also hope this Nugget was informative for you, and I'd like to thank you for viewing.

0:00Won't you be, please, won't you be my BGP neighbor? I just saw some YouTube footage of Mr Rogers' Neighborhood, and he was break dancing with this cute little kid. And you got to check it out. It's mind blowing. All right, so let's take a look at the BGP neighbor states. These can be critical when troubleshooting. When you really analyze the BGP protocol, you're not going to be surprised to learn that there are a lot of mechanisms built in to ensure stability. We want as stable a protocol here as possible.

0:34And you know something interesting about that? A lot of IGPs are engineered to be as quickly converging as possible. So the minute there's a change inside your organization, we want subsecond convergence of other devices, so we know about that change. BGP is engineered differently. Timers are way bigger than we would be used to with our IGPs, because we want stability. We'll trade convergence delays. After all, BGP is dealing with the public internet routing tables on service providers.

1:10They're absolutely massive. There's going to be delays expected with internet technologies, no matter how you shake it. But when it comes to stability, that's the key. When you look at the BGP neighbor states, you get a sense for this-- that it's almost paranoid in how many states that exist. There is an Idle state where the device is not initiating any of the other states, and then there's an Established state where it is fully established with its peer.

1:42But what's kind of surprising is there's all these in-between states of Connect, Active, OpenSent, and Active-- OpenConfirm, excuse me. So the Connect state is where it's waiting for the TCP connection with the neighbor to be completed. In the active state, it's actually trying to initiate a TCP connection with its neighbor. In the OpenSent state, as you might guess, it has sent its Open message, and it's waiting to hear back from its neighbor with its Open message.

2:15And then in the OpenConfirm state, it's actually waiting for the keepalive, based on the successful exchange of the Open messages. Hopefully, it gets a keepalive. If there's some type of error, of course, it would get a notification message. Now the great news for your support engineers is they can confirm what's going on with the BGP state at the respective CLI. In the case of Cisco, it is a command that's really trouble for students to memorize.

2:47You see, when we want to verify neighborship in something like an IGP in the Cisco world, it's show ip ospf neighbor, for example. Or how about for EIGRP, show ip eigrp neighbor. Notice neighbor is in the keyword. Not so with BGP. What we do with BGP is we do show ip bgp, and then the summary keyword. So this can be tough to remember, but notice when I run show ip bgp summary, it does show me my neighbor table.

3:19And we've got a problem. We are in the Idle state. So this device has basically given up on its neighbor at 10.12.12.1. And I don't blame this device, because the neighbor at 10.12.12.1 is not properly configured for BGP. So we are just sitting here in this sad little lonely state of Idle. So what we can do, obviously, in this demonstration, is let's go over.

3:49I'll do this in the background. And I'll enable our one properly with BGP. And then, of course, we'll see the change on this router. All right, R1 is ready to play nice. And the first thing that we notice is we do get a syslog message that's really great news that we have that neighborship up. Now, if we re-check with our show ip bgp summary our neighbor table, first of all, notice that we get a whole bunch of information about the configuration of BGP now that we are established.

4:20But look at this. Under state. We no longer have one of our states explicitly listed. So it's not established, written here, that is the state we're in. But instead it says prefix received is another option that we might see here. And that's exactly what's happened. We have received a prefix from that neighbor. So we are established, and we get the additional bonus information that we have a prefix from that device.

4:52We certainly want to think about these neighbor states in our troubleshooting efforts with Border Gateway Protocol. And remember, we are really troubleshooting two things, aren't we? We're troubleshooting the application layer protocol that is BGP, but we might also have to troubleshoot TCP, because this protocol is relying on the TCP transport layer protocol. We know it's port 179. So a frequent mishap is engineers will forget to open this port appropriately on security devices, and they'll be stuck in that lonely Idle neighbor state.

5:32I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00When your device gets a BGP prefix, there is going to be many-- what we call-- path attributes tagged to it, and we know that these are going to be critical, when it comes to BGP doing things like choosing a very best path to a destination. There are so many path attributes, and something that we need to wrap our heads around, is the fact that all of these are not created equal. We can put all of our path attributes into four main categories-- well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive.

0:37So to master this concept, we can first, go on this first word-- well-known or optional. Well-known means that all routers must recognize this path attribute. And then, as you might guess, the optional key word here, means that-- and it's not a keyword at the command line, I shouldn't say keyword, I suppose-- but optional means that the BGP implementation, doesn't really have to recognize that path attribute at all. So well-known, everybody's going to recognize that attribute.

1:11Optional, the attribute may be some new feature that not everybody is going to recognize. So then, we have mandatory and discretionary-- if I can say that-- associated with the well-known. This means that the update-- let's say, from our neighbor-- must contain that attribute. Period. End of story. It must be there. If it's not there, a notification error message will result, and the peering will be torn down. Discretionary, of course, then, would mean it doesn't have to be in the update.

1:44Then with are optional attributes, there's transitive and non-transitive. And this simply means, if it's transitive, the device needs to pass that path attribute onto its next neighbor. If it is non-transitive, it can just ignore that attribute value. So these are the categories, and it's important to know them. So what would be examples of each of these? Well, with the well-known mandatory, I want to give you three examples, they're so critical.

2:19There is the origin path attribute-- how did the BGP prefix get into BGP in the first place? There's the AS path attribute, that I speak so often of. And then, there's the next hop attribute. And it makes sense that these would have to be in these prefixes, as far as their attributes go, because they are indeed, so critical. We know AS path is going to be used in the route determination, and it's also a loop prevention mechanism.

2:49And how can we get to the prefix, if we don't know the next hop to get there? An example of a well-known discretionary attribute would be local preference-- something that we can use to manipulate the path decision. An example of an optional transitive attribute would be the communities attribute, where we can group prefixes together as part of what we call a community value, in order to treat them all the same with some treatment that we are doing, as far as routing policy goes.

3:22And then, an example of an optional non-transitive path attribute, would be the multi-exit discriminator, or MED value. We see this value reported to us on a Cisco command line as the metric. And this is very confusing because those of us that are coming from a heavy IGP background, we think of the metric as the one value that dictates the path decision, and that's not what we're talking about here.

3:53So I wish they didn't call it the metric at the command line. I wish they'd simply called it, MED, which again, stands for the multi-exit discriminator. It's something that we will be looking at in our BGP Nuggets in great detail. Let's go to the Cisco command line and do a show IPBGP, in order to look at the BGP table that's on this device. Note, this is not the routing table. It's the BGP table. And we better see the three well-known mandatory path attributes for this prefix or we got big problems.

4:28There's the next hop path attribute. Great, that's there. There's the AS path attribute. Excellent, that's there. And here is the origin code. So sure enough, for this prefix in the BGP table, it does contain all three of the well-known mandatory attributes, as it well should. In this Nugget, you and I discussed the four categories of path attributes. We have well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive.

5:00We also discussed examples of each. I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00My origin is Worcester, Massachusetts-- specifically, St. Vincent's in Worcester, Massachusetts-- in 1969, November 15th, at 7:00 AM. Enough about that. But the origin attribute in BGP is an attempt to record where a prefix came from. Let's take a look at this really interesting attribute. There are three possibilities when it comes to the origin for this attribute. So three options that we would see here-- IGP, EGP, and a question mark, for incomplete.

0:38This is quite confusing. In fact, the first confusing thing-- and I think, Cisco did a fairly sloppy job here, really-- the first thing that can be a bit confusing, is you can see they use a lower case i to indicate something in the output. And then, a lower case i to indicate something else. I wish those were different. Notice this lower case i, has to do with a potential status code that we would see upfront in this output. And this lower case i, is the origin code, which is back here in the output.

1:08So for this prefix, I can see that the origin is IGP. Now that's a bit of a head scratcher. Are they referring to interior gateway protocols? Yeah, they kind of are. This prefix made its way into this topology thanks to the network command inside of the configuration of that source device. That means, that we're assuming-- or the authors of this technology are assuming-- that that came from an interior gateway protocol entry.

1:42So in our, let's say, OSPF routing table, we have this prefix. And then, we use the network command inside of BGP, to put it into the BGP ecosystem. So the ultimate origin is like an IGP. See how that works? Now this is kind of funny. EGP is referencing the exterior gateway protocol-- the predecessor protocol to BGP. So we are never going to see this origin code anymore.

2:15We can basically ignore this. It's just a legacy thing. And then, incomplete means that BGP really can't tell us exactly how it got in. The most common scenario here, is that the prefix was redistributed into border gateway protocol from some other protocol. Now that means on our routes, we are going to see what two possibility codes here in Cisco output?

2:45Sure, we're going to see a lowercase i or we're going to see a question mark. That is it. Why we care about this is, when we look at the BGP best path selection algorithm, this is one of the tiebreakers-- the origin code of the prefix-- as far as what would be the best path. So the origin attribute-- a well-known, mandatory attribute that must exist with our prefix. And we saw in this Nugget, that it can have a value of IGP, EGP, or the question mark, for unknown.

3:22And we also know, that we would never see the EGP entry. I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00Ladies and gentlemen, it's time for the star of the show, the main event, the AS_PATH attribute. All kidding aside, we know this is a well known mandatory attribute, and we know that it is absolutely critical for the best path decision, as well as loop prevention inside a border gateway protocol. Here is how the AS_PATH attribute is going to work very specifically. Let's say we have the 1.1.1.0/24 prefix up in this AS.

0:32Over eBGP when this prefix is sent, the AS is going to be pre-pended to the AS_PATH attribute. So in this case, it's going to be just adding 65111. When this device gets it, notice it's an iBGP pairing it has. It will not add its own AS. And then this device will send it on this way. It's not going to add its own autonomous system in the path, because, again, we're dealing with iBGP, but, uh oh, eBGP to send it this way, so this is where the pre-prending come in.

1:10Pre-pending means it will add its AS to the beginning of that path. So what we would expect to see on this device when we look at-- or in this AS, I should say, when we look at this prefix, we expect to see an AS_PATH of 6522 on the left and then 65111 after that. Well, I'm sure you're not surprised. I've got this built for us.

1:41Let's go take a look if this is indeed happening. So here's our topology in GNS3, and let me just kind of remind you, so here is our 65111 autonomous system and then these three devices is that 65222. And then finally, we have this guy over here at 65333. Let's go to the command line and see the AS_PATHS that we have as a result. So here on our 1 in 65111 where we have the prefix originated, if I do a show IP BGP, we see that from a path perspective it's empty.

2:24And that's exactly what we would expect. It's the origin of that prefix, so there is nothing in the AS_PATH there. And notice this I is the origin code, and that just, kind of, made its way all the way into this path column, because there is no path to report. But if we go down to someone that lives inside of 65222, how about the R4 device, and we do our show IP BGP, there's the prefix.

2:55And sure enough, it shows the path of 65111. So it does have that entry inside AS_PATH for that AS in which the prefix was originated. Perfect. And now, of course, let's go all the way over to R5, do our show IP BGP, and there is the complete AS_PATH that we expected to see. Notice on the right side, the AS of origin if you will, 65111 and then 65222 was pre-pended to that, put at the beginning of the AS_PATH and that's who we received this prefix from.

3:39And one of the fun things you can do with BGP is you can literally look at the global BGP table. This is with Looking Glass servers. If you do a Google search on BGP Looking Glass, you'll find plenty of options that will allow you to peer into the global BGP table. So I've done, so with this hurricane electric internet services Looking Glass, and notice it's taken my IP address and it's shown me where my subnet is available inside of the global BGP routing table.

4:11And look at the path. You can see that these folks have learned of my prefix from a source of 33363, and then they were given the prefix from the AS 7843. So this AS_PATH is a critical path attribute and now we can interpret it just fine. You just can't overlook the importance of well-known mandatory BGP attributes, and AS_PATH is one of those.

4:42We know there's Origin, AS-PATH, and we also know there's Next Hop as well known and mandatory. I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00It's really no surprise that a BGP prefix has an attribute called NEXT_HOP. After all, a router is going to need to know where to send traffic for that prefix. And the NEXT_HOP attribute fulfills this need. But what's interesting about it is, it does not work like our interior gateway protocols. Let's take a look at that fact in this Nugget. If we were thinking about an interior gateway protocol, when this device sends an update to its neighbor, the next hop would be this interface right here.

0:32And then of course, when this device sends it to this device, then the next hop would be here. And the next hop would be a hop-to-hop type of value. But that's not how our BGP protocol works. When we have eBGP and the prefix is sent, this router right here will see the next hop as the eBGP advertiser of that prefix. But this is going to be retaining this value as it sends it through the iBGP.

1:03So this is a unique characteristic. The next hop, as this router would see it, to that prefix is going to be way out here, the originator of that prefix from an AS perspective. And this can cause some interesting issues. Something else that's interesting is, with iBGP, it will be the interface of the iBGP prefix. So if this device right here originates some prefix and sends it via iBGP into this cloud, then this device would see that as the next hop, not this device.

1:41I know this may be a little confusing. Let's take a look at this on the command line. And let's see some interesting problems that can result from this behavior. If we look at the R1 device in our topology, this device is originating the prefix for the 1.1.1 network. And because it's originating that prefix, notice it has a Next Hop of quad 0. That would make sense, as it's the originator of the prefix. Now we're on our R2. This is an eBGP peer of that device.

2:12And notice the Next Hop is set to the R1 interface. This makes sense, even from an iGP perspective. But what's going to be interesting is this Next Hop value is going to be carried when it sends this entry to its iBGP peer. And sure enough, now we have a problem. Look at this. The prefix does show up on R3 with the Next Hop of that next autonomous system that it came from that Next Hop of 10.12.12.1.

2:47And notice, it is not considered a best path. This path isn't, this prefix, I should say, isn't making its way into the routing table. And that's because the Next Hop of 10.12.12.1 1 is listed as inaccessible. This device, if we do a show ip route, has no route to the 10.12.12 network. So in order for this prefix to be established here, we would need to use a static route or some method to educate this device how to get to that next hop.

3:27Now, there is a little cheat we can apply, and this is a best practice. And that is to go to the R2 device and say that it should override that Next Hop value. So we'll go into this device and we'll say, router bgp 65. This is the 2222 autonomous system. And we'll say, look, on your neighborship to the 10.23.23.3 device for Next Top set yourself as the Next Hop.

4:01That's it this little kind of Band-Aid for Next Top should take care of it. Let's go over to R3. And let's see if this kicked in right away. We'll do a show ip bgp. And no, nothing yet. So it's still not seeing that new Next Hop information. Let's force it very bluntly. We'll go, clear ip bgp asterisk, and we'll reset our BGP sessions.

4:32Now we'll go over to R3. We see that the sessions have reset. And we'll do a show ip bgp over there. And look. Now things have been updated. And now we're in good shape. If I do a show ip bgp, and we specify that prefix to get more information, we'll see that there is a best path available, and that the Next Hop is now 10.23.23.2. And that is the R2 device that said, use my Next Hop.

5:06We know how to get to that device. So now the prefix is being implemented as the path is perceived as reachable, which it is, of course. So when you're thinking about that important NEXT_HOP attribute in BGP, don't really think router to router. Think more autonomous system to autonomous system with it. And that will get your head clear on how this works. And it will also get you thinking about reachability issues that could result, as we saw in this Nugget, where some internal BGP device does not know how to get to the next hop, because it is a clear prefix entry that is way out of its autonomous system and is the entry point to the next autonomous system.

5:56Remember, AS-to-AS instead of router-to-router logic. I hope you found this Nugget informative. And I'd like to thank you for viewing.

0:00Now, let's deviate a little bit in our discussion of path attributes and border gateway protocol. One of the super interesting ones is weight. This attribute is so interesting because it is specific to Cisco. Now, Cisco is such a giant in the industry that many other vendors will recognize weight. But this attribute is so unique. Let's discuss it in depth here. Weight, it turns out, is a value that is assigned to our prefixes, and the first very unique thing about it is it only on a router, and this information does not get passed to any other router-- interesting.

0:45So there is this weight attribute, but the devices are not advertising this weight. It's for local use only. It turns out the weight is a simple number from 0 to 65535. And the higher the weight value, the higher the preference. So a bigger weight here is better. I sure wish that was under my Weight Watchers rules. But anyways, something else that's interesting about weight is that when the prefix is locally generated, it will get a weight of 32768.

1:25Otherwise, the default weight is zero for a prefix. So before we look at this at the command line, let's think about how it might be used. Let's say this AS right here is advertising the 111 prefix and so is this AS. So we have the 111 prefix being advertised from here as well. So certainly, on a device down here in this topology, it has two potential paths to get to that prefix.

1:57Well, sure enough, the administrator of this device has this weight value that they could go in and manipulate for one of the prefixes. All they would need to do to influence the path decision-- let's say that way is to set this prefix coming in from that direction-- to a higher weight value. And now, they can easily override the routing decision. They can prefer the path very quickly on that device utilizing the weight value.

2:30We got to remember, though, that this is a local setting only and is not advertised to other peers. So you need to use weight very carefully. Let's confirm all this at the command line quickly. If we go to R1, and we do a show IP BGP, this is the originator of that 111 prefix. So just as we expected, the weight is set on that local router for that prefix of 32768.

3:03If we go over to another router, let's say R2 and another AS, and we do show IP BGP, we see that the weight is set to zero as we indicated. This device didn't originate that prefix. It learned of that prefix from another device, and it installed it in the BGP table with that weight of 0. We could go in and manipulate that weight, of course, on this local device, but it is going to default to that zero value.

3:35The Cisco invention of BGP weight-- an amazingly powerful way on a local device to give influence to one path over another. Key being, on that local device only, though, as weight, as we've learned, is not advertised to other peers. I hope you found this Nugget informative, and I'd like to thank you for viewing.

0:00It's so interesting to compare BGP to IGPs. We know that the IGP has a metric, that in the case of OSPF for example, is based on cost which is directly based on bandwidth. And this is the big path determinant. With BGP, there are many path attributes that a prefix can have. And sure enough, these all lend themselves to the BGP Best Path Selection Algorithm. Now, as you look at this complex path decision, you may immediately think, why does it have to be this complicated?

0:37It's this complicated because remember when we're dealing with something like the internet prefixes is ISP to ISP communications, we want there to be as many tuning knobs as possible for policy. We want to be able to control as much as possible how prefixes are being shared and preferred throughout such a large complex network. Now, notice that I have inside here this table the word Cisco.

1:08This is Cisco's look at the BGP best path selection process, and the vendor, Juniper, might do it slightly differently. In fact, in this Nugget, I'll show you how they would go about it. So the great news is, though, is there's going to be so many similarities on some of this stuff on how the vendor would do it. For instance, the shortest AS path decision would come before the lowest MED with both Cisco and Juniper and someone else that is implementing this technology.

1:46So there is going to be consistency there. Highest weight makes sense that it's a Cisco thing and is considered first. And it makes sense that Juniper wouldn't even recognize weight because they don't, and it's not in their best path selection. Now, the other important thing to realize is that there are tests that are going to be done before this even kicks in. We talked about how NEXT_HOP must be accessible, for instance, before one router would advertise that prefix to another router.

2:22So keep in mind that routes-- prefixes-- may not even make it to this best path selection if they don't meet some criteria like a reachable NEXT_HOP. Once they do get to this point, though, the analysis starts from the top down. So the highest weight-- if there is a difference in weight values, then that's going to be the preferred path. The highest local preference attribute-- if that's there, and there is a difference, then it would be used, and the algorithm doesn't have to look any farther.

2:57Notice that when we get down here, it's like almost random tiebreakers. You can really see that with the last gasp at picking a best path of multiple paths, and that's the lowest neighbor IP address. So if your neighbor has like 10.10.10.1, then it would be chosen that path as opposed to someone else that has like 172.16. So there has to be a selection of the very best path, and it'll use an arbitrary tiebreaker if it has to.

3:33If you happen to be studying for something like a Cisco certification exam, maybe you're studying for your CCIE certification in the route switch category, you pretty much have to memorize this as far as what's first what's second? Where's AS path determinant? Where's MED? And you'll see these students making flashcards to help them memorize the order and also memorize things like is a higher weight better or lower weight?

4:04Is a higher local preference better or lower local preference better? So these are really tried and true certification exams for Cisco that would come out of this chart. Now, I promised you we would take a look at the Juniper Best Path Selection algorithm for Border Gateway Protocol and here it is. We noticed that there is some proprietary things to Juniper-- like Cisco had a proprietary weight value. Notice Juniper you could turn on something called the accumulated IGP value.

4:35So this would be the second thing that would be looked at. Notice when it comes to attributes that are well known like local preference, it comes before AS path which comes before lowest MED. So there is a consistency in those really big important parameters-- well worth noting. And then, sure enough, Juniper would do something like kind of panic at the end and use an arbitrary value like lowest neighbor address just as Cisco did. So with an interior gateway protocol like OSPF, it's pretty darn simple-- lowest cost path wins.

5:11But with Border Gateway Protocol, there's many more policy controls and a much more sophisticated Best Path Selection Algorithm. In fact, it's called an algorithm because of its sophistication. I hope you found this Nugget informative, and I'd like to thank you for viewing.