Border Gateway Protocol (BGP): Basic Operations

0:00In this Nugget, you and I are going

0:01to take a look at some of the properties that

0:04make border gateway protocol just incredibly unique,

0:08especially when we compare it to other routing protocols.

0:11If you haven't thought about BGP in a while,

0:13this Nugget's going to serve as a great review.

0:17The very first thing that makes BGP so unique,

0:20is what it does for us.

0:21It is our only exterior gateway protocol in major use today.

0:27So we have our interior gateway protocols,

0:30and that would be like OSPF running inside of an autonomous

0:34system, but BGP is an EGP, which means

0:38that it is going to take prefixes that

0:40are inside an autonomous system and send those

0:43to other autonomous systems.

0:45This is why BGP is the protocol that

0:48makes the internet function.

0:50Internet service providers can use BGP in order

0:53to move prefix information between other internet service

0:57providers.

0:58The unique characteristics of BGP

1:01don't just stop there, though.

1:02One of the things that's amazing about it

1:04is, it forms point-to-point peerings with other devices.

1:09So there's no such thing as forming a neighborship

1:12with a whole bunch of devices on the same segment.

1:16It won't do that.

1:17For each of the devices it needs to peer

1:19with, it does so on a single peer-to-peer, what we call,

1:23BGP peering.

1:25BGP is also, an application layer protocol,

1:29instead of running at like the network layer of the OSI model.

1:33So as an application layer, it does something brilliant.

1:37It leverages transmission control protocol

1:40for its operations.

1:42If you look at EIGRP, for example,

1:45they wanted reliability in the communications with the IGRP

1:49so they had to build that into the protocol.

1:52One example is, an EIGRP speaker will try and multicast

1:57transmissions, and if that's not working out,

1:59it will fall back to unicast transmissions,

2:02as a way to try and ensure reliability.

2:05With border gateway protocol, the engineers said,

2:07you know what?

2:07We're not going to try and engineer

2:09all that into the protocol.

2:10We'll just rely on the wonders that

2:12are the reliable communications of TCP.

2:16It uses TCP port 179 then, in its operations.

2:20And allows TCP to take care of the reliability that

2:24needs to happen between these peerings.

2:28Now when you look at a typical routing protocol,

2:30we know that there is going to be some value that

2:33is going to be the metric.

2:35For instance, in the case of OSPF,

2:37we know the metric is cost, and cost

2:40is based directly on one value and that is bandwidth.

2:45BGP does not work that way at all.

2:48BGP uses attributes-- we call them--

2:51instead of just a single metric, and one

2:54of the prime attributes of BGP is called the AS path

2:59attribute.

3:00And this is a list of all of the autonomous systems

3:05that a prefix has had to transit on its journey to,

3:09let's say, your autonomous system.

3:12So it's a recording of all of this AS path information.

3:16The AS path is so critical to the function of BGP,

3:20that the protocol is referred to as a path vector protocol.

3:25Not distance vector, but path vector.

3:29The AS path is not only used to gauge what would be the best

3:34path to a destination-- thus the shorter AS path--

3:38it is also used as a loop prevention mechanism.

3:41When an autonomous system sees its own AS number

3:45in the AS path, it gets very concerned

3:48that there may be a loop in the communications.

3:51Something else that makes BGP incredibly unique,

3:54is the fact that when we form peerings inside an autonomous

3:59system, these are called internal BGP peerings.

4:04And when we are forming a peering between autonomous

4:07systems, this is called exterior border gateway protocol.

4:11You might ask, Anthony, why do I care?

4:14And why does the protocol care?

4:16And that's a valid question.

4:17The reason why we distinguish between an IBGP

4:20peering and an EBGP peering, is that

4:24operational characteristics are going

4:26to need to change based on how the peering is done.

4:29For example, we said there's this AS

4:32path that is recording the autonomous systems that

4:35are transited.

4:36Clearly, over an EBGP peering, when a prefix

4:40is sent from this AS to this AS, this AS

4:43must put its autonomous system in the path.

4:46But with IBGP, they're sending the prefix to each other,

4:51and they don't want to put their own AS in the path

4:54when they hand it off to another device.

4:57So the rules are going to change when

5:00we're talking IBGP versus EBGP, in order

5:04to keep things consistent and error free.

5:08And the unique properties of BGP just don't end here.

5:12We're going to see, again and again, as we examine these BGP

5:16Nuggets, that there is just going to be case after case,

5:20where the protocol operates in a very different manner from what

5:24we would expect with our IGP brethren.

5:28I hope you found this Nugget informative,

5:30and I'd like to thank you for viewing.

0:00Many people describe Border Gateway Protocol

0:03as an extremely complex protocol,

0:05but I don't think that really tells the story.

0:08You see, BGP policies and controlling prefix propagation

0:13inside of BGP, that can be super complex.

0:16But the protocol itself, while unique,

0:19is pretty simplistic in its operation.

0:22In this Nugget, we're going to take a look at that as we

0:24examine the BGP message types.

0:27When this router right here wants

0:29to begin an eBGP peering with this router right here,

0:32it is going to rely on Transmission Control Protocol.

0:35And, of course, we know there's going

0:37to be a three-way handshake with TCP

0:40in order to start that reliable communication session.

0:44What's going to happen then is these devices

0:47are going to exchange open messages.

0:50The open message contains very important information.

0:54The primary ingredient of which is the autonomous system number

0:58of the peer.

0:59This is going to determine whether it's

1:00an eBGP peering or an iBGP peering.

1:04When the open messages are exchanged,

1:07they'll then start exchanging keepalive messages.

1:10This, of course, is a simple little mechanism

1:12to make sure the other device is there, happy, and healthy,

1:17so that the peering can remain up.

1:19When they have updates to share, it's

1:22a simple update message that is transmitted.

1:25And if anything goes wrong at any point,

1:28they can use a simple notification message

1:31in order to tear down the peering

1:33as a result of some error that may be happening with BGP.

1:37There is a route refresh message type.

1:41This is not in the original standard.

1:44So this is in addition.

1:45But the great news is most of our major networking vendors

1:49support route fresh behavior.

1:51And route refreshes allow the neighbors to update, let's say,

1:56BGP route information or even update things

2:00after a pretty major policy reconfiguration

2:04without tearing down the peering or affecting the peering

2:07in any big negative way.

2:08So they can stay peered up just fine

2:11after reconfiguration events.

2:13And most times these reconfiguration events,

2:15as I've stated, are going to be because of some policy

2:18manipulation that we want to make.

2:21Let's bring this discussion to life with some Cisco routers.

2:25Here, we're going to have R1 peer with R2.

2:28And what we'll do is we'll examine the messaging that

2:32is utilized between these two devices during the peering.

2:35I'll use that topology that we've been looking at.

2:37So R1 will be in AS 65111.

2:41And R2 will be in AS 65222.

2:46Because we want to examine the actual packets,

2:48we will right-click this link, and we

2:50will start a capture on that link utilizing Wireshark.

2:55Things aren't very exciting on that serial link right now.

2:58It's a bunch of SLART messages.

3:00And the Cisco Discovery Protocol is

3:03all that is being transmitted between those two devices.

3:06But I have a feeling, based on our discussion,

3:08things are about to change.

3:11Here on the R1 device, I'll enter

3:12Global Configuration mode.

3:14And I will say router bgp 65111 and hit Carriage Return.

3:21We're now in Router Configuration mode for BGP.

3:24And I will set up the peering on this side.

3:27I say neighbor.

3:28And it's 10.12.12.2, the IP address that's

3:33on R2's serial interface.

3:35And we use the remote as keyword in order

3:39to indicate that the remote AS is at 65222.

3:43We hit Carriage Return.

3:45We exit.

3:46And that's it.

3:47We can exit one more level to get back to Privilege mode.

3:51Now let's fire up R2 and do the same thing.

3:53So Global Configuration mode, router BGP.

3:57This AS, of course, is 65222.

4:01And then we are going to specify our neighbor of 10.12.12.1.

4:07Our remote AS is 65111.

4:11Carriage Return.

4:12This time I'll be more precise and say end,

4:15and we go all the way back to Privilege mode.

4:17Now, look at what just happened.

4:19I was hoping this would happen.

4:21We just had a BGP adjacency change.

4:25We now have a peering with that device.

4:28So our two configuration commands,

4:31the two neighbor commands on each device, we did properly.

4:34And we have an eBGP relationship built.

4:38Let's see what's going on in Wireshark.

4:41If we scroll down in Wireshark, I'm

4:44thinking we're going to see some TCP messages.

4:48And there they are.

4:50Those TCP messages are establishing the connection

4:54using the reliable Transmission Control Protocol.

4:58And we can see just from the summaries

5:00here that 179, port 179, is involved in that handshake.

5:06Then we can see the BGP messages.

5:09Look at this.

5:09We have our open messages that are exchanged between the two

5:12devices.

5:13They start doing their keepalives.

5:16There's an initial exchange of update messages

5:19to make sure that their databases are

5:22in sync with each other.

5:23And when I say their databases are in sync with each other,

5:26there's not much to sync.

5:28These devices don't have any prefixes

5:31to advertise to each other.

5:33So let's fix that, and let's see what

5:35happens inside of Wireshark.

5:37I'll create a loopback zero interface on R1.

5:41And I'll give this an IP address of quad ones

5:45with a 24-bit mask.

5:47And then we'll go into BGP on this device.

5:51And let's see, 65111, and we will advertise that network

5:57with the network command.

5:59So it'll be the 1.1.1.0 network with a mask of 24 bits.

6:07So notice, the network command in BGP

6:10will take care of that advertisement.

6:12Let's go back over to Wireshark.

6:14And now we should see an update worth

6:17examining when it comes to BGP.

6:20And there it is right there.

6:23And if we look inside the Border Gateway Protocol update

6:27message, notice, we have Network Layer Reachability Information.

6:32And there is the prefix that this R1 is advertising to R2.

6:39Notice it's called Network Layer Reachability Information,

6:43or NLRI.

6:45One of the most fascinating things about Border Gateway

6:48Protocol is that it was designed to carry whatever information

6:54you needed to carry.

6:55In our usage, it's carrying IPv4 route prefixes

7:00as we can see here.

7:02But it could carry other information.

7:05We call this capability multi-protocol BGP.

7:09So keep that in mind.

7:11This is an extremely flexible protocol.

7:14And it can carry more than just IPv4 prefixes.

7:19In this Nugget, you and I examined, literally examined,

7:23the message types that are used by BGP.

7:26We know there's the open message.

7:28There's the keepalive message.

7:30There's the update message.

7:31There's the notification message.

7:33Hopefully, we don't deal with that a lot,

7:35because it indicates that there's an error.

7:37And then there also the route refresh

7:39message, which was added for additional functionality.

7:43I hope you found this Nugget informative.

7:45And I'd like to thank you for viewing.

0:00In this Nugget, you and I are going

0:01to learn even more about the operational characteristics

0:05of border gateway protocol, by taking our BGP message types.

0:10And we remember, that's the open, update, notification,

0:14keepalive messages.

0:16And we're going to put those under the microscope

0:18by seeing the fields inside them.

0:20Each message type is going to have a BGP header, of course.

0:25And the header information has this pretty darn big marker

0:29field.

0:29You would think this is hugely important.

0:31It's 16 octets, this field.

0:34But it turns out, that this is just going

0:36to be filled with all ones.

0:38That's because the use of this marker field

0:41has been deprecated in the standards.

0:44The original idea for this field,

0:46was that it could be used to detect

0:49like a loss of synchronization between two peers,

0:52and it was also thought, that this

0:54would be the area in which authentication

0:56information could be held.

0:58But 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

1:05there, of course, in case there needed

1:07to be backward support with some really old BGP device, that

1:11expects to see this marker information.

1:14So the important fields here in the header,

1:17are going to be length--

1:19which is the length of the overall message--

1:22and then, the type field.

1:23The type field indicates what type of BGP message

1:26we're dealing with.

1:28If you see a one in here, you're dealing with an open.

1:30A two, would indicate an update.

1:33A three, would indicate a notification.

1:35A value of four, would be a keepalive.

1:38And then, a five would be that optional route refresh

1:41behavior.

1:42Note, that there will then be data, perhaps.

1:46Now what do you mean by, perhaps?

1:48Well data won't follow this header

1:50in the case of a keepalive.

1:52A keepalive is going to be a message type

1:55that we'll look at, and that message format says

1:58that there won't be any data with the keepalive message.

2:02Now I'm sure you recall, when your system

2:04wants to form a BGP peering with another device,

2:07it's going to send an open message.

2:10And when we look at the open message format,

2:12we note that there is a version number-- whoa,

2:15I've got the wrong pen.

2:17Let me grab the right pen here.

2:18There we go.

2:19So there's a version number.

2:21So we expect future versions of BGP,

2:24and that's how you could indicate the version of BGP

2:27that you're using.

2:28Your system is also going to send it's AS number

2:31in the open message-- this is critical,

2:33of course, for that IBGP verse EBGP type behavior.

2:38There's a hold time value, and what's interesting

2:40about the hold time is you're going to have your hold

2:44time in this field, and when the person that you want

2:47to peer with receives this, it will look at that hold time,

2:51look at its own configured hold time,

2:54and then, use the smaller of the two values.

2:57The hold time-- by the way-- needs

2:59to be either zero or at least, three seconds.

3:04So you can negate hold time with the zero value,

3:07but if you're going to set hold time,

3:09it needs to be three seconds or greater.

3:11Then there's your BGP identifier.

3:14This is your BGP router ID, and this

3:17is a critical value that's going to distinguish your system

3:21uniquely, in the BGP peering.

3:23Then, we finally have optional parameters

3:26that could be set with the open message.

3:29There's an optional parameter length and then, the parameters

3:32themselves, to give us added flexibility with the protocol.

3:36Another really important message that we have

3:38is the BGP update message, and when

3:41we look inside this message, we see

3:43that there's going to be an indicator for withdrawn routes

3:47length.

3:48So the update message is a great way

3:51that one BGP speaker can make sure

3:54that routes are withdrawn from the BGP table of its neighbor.

3:58And that list of withdrawn routes

4:00can be in the update message.

4:02Notice then, when we are telling someone about an update--

4:07an additional prefix-- we're going

4:09to be making sure that we specify the attributes that

4:13go with that prefix.

4:15A well-known attribute that we have already mentioned

4:18is AS path, that list of paths that the prefix

4:23has transited on its way throughout the BGP

4:26infrastructure.

4:28So AS path would be an example of an attribute.

4:31There can be many attributes that we are utilizing, thus,

4:34we need to specify the length in the update message.

4:38And then, the attribute information.

4:40And then, finally, in the update message,

4:43of course-- and we saw this within Wireshark--

4:45we need to see the network layer reachability information.

4:50And as we indicated, the great thing about NLRI,

4:54instead of this field just being designed for an IPv4 prefix,

4:59is that it gives us flexibility.

5:01BGP is built to start immediately running things

5:05like IPv6 for us.

5:07Or VPN IPv4 prefixes inside of something like an MPLS VPN.

5:15We can't forget about our little friend, the keepalive message

5:18in BGP, and notice, I've just drawn for us here,

5:21the header itself.

5:22Because remember, the BGP keepalive

5:25is going to a BGP message that just has the header

5:29information in it, no data.

5:32And then finally, we have our BGP notification message.

5:35And we sure hope we don't have a lot of these, but notice,

5:38there's an error code.

5:40And then, there's an error sub code,

5:42to give us a general type of error

5:45and then, even more information.

5:47Let me give you an example.

5:49If in the error code, we have a value of three

5:52and then, in the error sub code, we have a value of three,

5:56this would indicate that there is an update message error.

6:01That's what this three would indicate

6:02so there's a problem with the update message.

6:05And then, this would indicate-- this three value--

6:08would indicate that there is a missing well-known attribute.

6:11So there's an attribute, like AS path,

6:14that we absolutely have to have, and it is not

6:18inside of that update message.

6:20This would be a massive error for us

6:23in the BGP infrastructure, and the peering would tear down.

6:27Studying exactly what's in our message

6:30types for our protocols, leads to a richer, deeper

6:33understanding of just how the protocol operates,

6:36and I hope you've seen that with this look

6:38at the BGP message formats.

6:41I also hope this Nugget was informative for you,

6:44and I'd like to thank you for viewing.

0:00Won't you be, please, won't you be my BGP neighbor?

0:04I just saw some YouTube footage of Mr Rogers' Neighborhood,

0:08and he was break dancing with this cute little kid.

0:11And you got to check it out.

0:12It's mind blowing.

0:14All right, so let's take a look at the BGP neighbor states.

0:18These can be critical when troubleshooting.

0:21When you really analyze the BGP protocol,

0:23you're not going to be surprised to learn

0:25that there are a lot of mechanisms built in

0:27to ensure stability.

0:30We want as stable a protocol here as possible.

0:34And you know something interesting about that?

0:36A lot of IGPs are engineered to be as quickly converging

0:41as possible.

0:42So the minute there's a change inside your organization,

0:45we want subsecond convergence of other devices,

0:49so we know about that change.

0:51BGP is engineered differently.

0:53Timers are way bigger than we would be used to with our IGPs,

0:58because we want stability.

1:00We'll trade convergence delays.

1:03After all, BGP is dealing with the public internet

1:07routing tables on service providers.

1:10They're absolutely massive.

1:12There's going to be delays expected

1:14with internet technologies, no matter how you shake it.

1:18But when it comes to stability, that's the key.

1:21When you look at the BGP neighbor states,

1:24you get a sense for this--

1:26that it's almost paranoid in how many states that exist.

1:30There is an Idle state where the device is not

1:34initiating any of the other states,

1:37and then there's an Established state

1:39where it is fully established with its peer.

1:42But what's kind of surprising is there's all these in-between

1:46states of Connect, Active, OpenSent, and Active--

1:51OpenConfirm, excuse me.

1:53So the Connect state is where it's

1:55waiting for the TCP connection with the neighbor

1:58to be completed.

2:00In the active state, it's actually

2:02trying to initiate a TCP connection with its neighbor.

2:06In the OpenSent state, as you might guess,

2:10it has sent its Open message, and it's

2:12waiting to hear back from its neighbor with its Open message.

2:15And then in the OpenConfirm state,

2:18it's actually waiting for the keepalive,

2:20based on the successful exchange of the Open messages.

2:24Hopefully, it gets a keepalive.

2:26If there's some type of error, of course,

2:28it would get a notification message.

2:32Now the great news for your support engineers

2:34is they can confirm what's going on with the BGP state

2:38at the respective CLI.

2:40In the case of Cisco, it is a command

2:44that's really trouble for students to memorize.

2:47You see, when we want to verify neighborship in something

2:50like an IGP in the Cisco world, it's show ip ospf neighbor,

2:55for example.

2:56Or how about for EIGRP, show ip eigrp neighbor.

3:01Notice neighbor is in the keyword.

3:03Not so with BGP.

3:05What we do with BGP is we do show ip bgp,

3:09and then the summary keyword.

3:11So this can be tough to remember, but notice

3:14when I run show ip bgp summary, it does show me

3:18my neighbor table.

3:19And we've got a problem.

3:21We are in the Idle state.

3:24So this device has basically given up on its neighbor

3:28at 10.12.12.1.

3:31And I don't blame this device, because the neighbor

3:34at 10.12.12.1 is not properly configured for BGP.

3:39So we are just sitting here in this sad little lonely state

3:43of Idle.

3:44So what we can do, obviously, in this demonstration,

3:48is let's go over.

3:49I'll do this in the background.

3:51And I'll enable our one properly with BGP.

3:54And then, of course, we'll see the change on this router.

3:57All right, R1 is ready to play nice.

4:00And the first thing that we notice

4:01is we do get a syslog message that's

4:04really great news that we have that neighborship up.

4:08Now, if we re-check with our show ip bgp summary

4:12our neighbor table, first of all,

4:15notice that we get a whole bunch of information

4:17about the configuration of BGP now that we are established.

4:20But look at this.

4:22Under state.

4:23We no longer have one of our states explicitly listed.

4:27So it's not established, written here,

4:30that is the state we're in.

4:31But instead it says prefix received

4:35is another option that we might see here.

4:38And that's exactly what's happened.

4:40We have received a prefix from that neighbor.

4:44So we are established, and we get the additional bonus

4:48information that we have a prefix from that device.

4:52We certainly want to think about these neighbor states

4:56in our troubleshooting efforts with Border Gateway Protocol.

4:59And remember, we are really troubleshooting two things,

5:03aren't we?

5:03We're troubleshooting the application layer protocol that

5:07is BGP, but we might also have to troubleshoot TCP,

5:12because this protocol is relying on the TCP transport layer

5:16protocol.

5:17We know it's port 179.

5:20So a frequent mishap is engineers

5:23will forget to open this port appropriately on security

5:26devices, and they'll be stuck in that lonely Idle neighbor

5:32state.

5:32I hope you found this Nugget informative,

5:34and I'd like to thank you for viewing.

0:00When your device gets a BGP prefix,

0:03there is going to be many-- what we call--

0:05path attributes tagged to it, and we

0:08know that these are going to be critical,

0:10when it comes to BGP doing things like choosing a very

0:14best path to a destination.

0:17There are so many path attributes, and something

0:20that we need to wrap our heads around,

0:21is the fact that all of these are not created equal.

0:25We can put all of our path attributes

0:28into four main categories--

0:30well-known mandatory, well-known discretionary, optional

0:34transitive, and optional non-transitive.

0:37So to master this concept, we can

0:40first, go on this first word--

0:42well-known or optional.

0:45Well-known means that all routers must

0:48recognize this path attribute.

0:50And then, as you might guess, the optional key word here,

0:54means that-- and it's not a keyword at the command line,

0:57I shouldn't say keyword, I suppose--

0:59but optional means that the BGP implementation, doesn't really

1:03have to recognize that path attribute at all.

1:06So well-known, everybody's going to recognize that attribute.

1:11Optional, the attribute may be some new feature

1:14that not everybody is going to recognize.

1:16So then, we have mandatory and discretionary--

1:21if I can say that-- associated with the well-known.

1:24This means that the update--

1:26let's say, from our neighbor-- must contain that attribute.

1:30Period.

1:31End of story.

1:31It must be there.

1:33If it's not there, a notification error message

1:36will result, and the peering will be torn down.

1:39Discretionary, of course, then, would

1:41mean it doesn't have to be in the update.

1:44Then with are optional attributes,

1:46there's transitive and non-transitive.

1:48And this simply means, if it's transitive,

1:52the device needs to pass that path attribute

1:56onto its next neighbor.

1:58If it is non-transitive, it can just

2:00ignore that attribute value.

2:03So these are the categories, and it's important to know them.

2:08So what would be examples of each of these?

2:12Well, with the well-known mandatory,

2:15I want to give you three examples, they're so critical.

2:19There is the origin path attribute--

2:21how did the BGP prefix get into BGP in the first place?

2:26There's the AS path attribute, that I speak so often of.

2:31And then, there's the next hop attribute.

2:34And it makes sense that these would

2:36have to be in these prefixes, as far as their attributes go,

2:40because they are indeed, so critical.

2:43We know AS path is going to be used in the route

2:45determination, and it's also a loop prevention mechanism.

2:49And how can we get to the prefix,

2:51if we don't know the next hop to get there?

2:54An example of a well-known discretionary attribute would

2:57be local preference--

2:59something that we can use to manipulate the path decision.

3:03An example of an optional transitive attribute

3:06would be the communities attribute,

3:08where we can group prefixes together as part

3:12of what we call a community value,

3:15in order to treat them all the same with some treatment

3:18that we are doing, as far as routing policy goes.

3:22And then, an example of an optional non-transitive path

3:26attribute, would be the multi-exit discriminator,

3:30or MED value.

3:31We see this value reported to us on a Cisco command

3:36line as the metric.

3:38And this is very confusing because those of us that

3:41are coming from a heavy IGP background,

3:44we think of the metric as the one value

3:47that dictates the path decision, and that's not

3:51what we're talking about here.

3:53So I wish they didn't call it the metric at the command line.

3:56I wish they'd simply called it, MED, which again,

3:58stands for the multi-exit discriminator.

4:00It's something that we will be looking at in our BGP

4:04Nuggets in great detail.

4:06Let's go to the Cisco command line and do a show IPBGP,

4:10in order to look at the BGP table that's on this device.

4:15Note, this is not the routing table.

4:17It's the BGP table.

4:19And we better see the three well-known mandatory path

4:24attributes for this prefix or we got big problems.

4:28There's the next hop path attribute.

4:31Great, that's there.

4:32There's the AS path attribute.

4:35Excellent, that's there.

4:37And here is the origin code.

4:39So sure enough, for this prefix in the BGP table,

4:43it does contain all three of the well-known mandatory

4:47attributes, as it well should.

4:49In this Nugget, you and I discussed the four categories

4:53of path attributes.

4:54We have well-known mandatory, well-known discretionary,

4:57optional transitive, and optional non-transitive.

5:00We also discussed examples of each.

5:03I hope you found this Nugget informative,

5:05and I'd like to thank you for viewing.

0:00My origin is Worcester, Massachusetts--

0:03specifically, St. Vincent's in Worcester, Massachusetts--

0:08in 1969, November 15th, at 7:00 AM.

0:13Enough about that.

0:14But the origin attribute in BGP is an attempt

0:18to record where a prefix came from.

0:21Let's take a look at this really interesting attribute.

0:25There are three possibilities when

0:27it comes to the origin for this attribute.

0:30So three options that we would see here--

0:32IGP, EGP, and a question mark, for incomplete.

0:38This is quite confusing.

0:40In fact, the first confusing thing-- and I think,

0:42Cisco did a fairly sloppy job here, really--

0:45the first thing that can be a bit confusing,

0:47is you can see they use a lower case i to indicate something

0:50in the output.

0:51And then, a lower case i to indicate something else.

0:54I wish those were different.

0:55Notice this lower case i, has to do with a potential status code

1:00that we would see upfront in this output.

1:03And this lower case i, is the origin code, which

1:06is back here in the output.

1:08So for this prefix, I can see that the origin is IGP.

1:13Now that's a bit of a head scratcher.

1:15Are they referring to interior gateway protocols?

1:18Yeah, they kind of are.

1:21This prefix made its way into this topology thanks

1:26to the network command inside of the configuration

1:30of that source device.

1:31That means, that we're assuming--

1:35or the authors of this technology are assuming--

1:38that that came from an interior gateway protocol entry.

1:42So in our, let's say, OSPF routing table,

1:46we have this prefix.

1:47And then, we use the network command inside of BGP,

1:52to put it into the BGP ecosystem.

1:55So the ultimate origin is like an IGP.

1:59See how that works?

2:01Now this is kind of funny.

2:03EGP is referencing the exterior gateway protocol--

2:08the predecessor protocol to BGP.

2:11So we are never going to see this origin code anymore.

2:15We can basically ignore this.

2:17It's just a legacy thing.

2:19And then, incomplete means that BGP really can't tell us

2:25exactly how it got in.

2:27The most common scenario here, is

2:29that the prefix was redistributed

2:33into border gateway protocol from some other protocol.

2:37Now that means on our routes, we are

2:41going to see what two possibility codes here

2:44in Cisco output?

2:45Sure, we're going to see a lowercase i

2:47or we're going to see a question mark.

2:49That is it.

2:50Why we care about this is, when we look at the BGP best path

2:55selection algorithm, this is one of the tiebreakers--

2:59the origin code of the prefix--

3:02as far as what would be the best path.

3:05So the origin attribute--

3:08a well-known, mandatory attribute that

3:11must exist with our prefix.

3:14And we saw in this Nugget, that it

3:15can 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.

3:26I hope you found this Nugget informative,

3:28and I'd like to thank you for viewing.

0:00Ladies and gentlemen, it's time for the star

0:02of the show, the main event, the AS_PATH attribute.

0:07All kidding aside, we know this is

0:08a well known mandatory attribute,

0:11and we know that it is absolutely

0:13critical for the best path decision, as well

0:16as loop prevention inside a border gateway protocol.

0:20Here is how the AS_PATH attribute is going

0:24to work very specifically.

0:25Let's say we have the 1.1.1.0/24 prefix up in this AS.

0:32Over eBGP when this prefix is sent,

0:36the AS is going to be pre-pended to the AS_PATH attribute.

0:42So in this case, it's going to be just adding 65111.

0:48When this device gets it, notice it's an iBGP pairing it has.

0:52It will not add its own AS.

0:55And then this device will send it on this way.

0:57It's not going to add its own autonomous system

1:01in the path, because, again, we're dealing with iBGP,

1:04but, uh oh, eBGP to send it this way,

1:08so this is where the pre-prending come in.

1:10Pre-pending means it will add its AS

1:14to the beginning of that path.

1:17So what we would expect to see on this device

1:21when we look at-- or in this AS, I should say,

1:24when we look at this prefix, we expect

1:28to see an AS_PATH of 6522 on the left and then 65111 after that.

1:37Well, I'm sure you're not surprised.

1:39I've got this built for us.

1:41Let's go take a look if this is indeed happening.

1:46So here's our topology in GNS3, and let

1:49me just kind of remind you, so here

1:51is our 65111 autonomous system and then

1:56these three devices is that 65222.

2:00And then finally, we have this guy over here at 65333.

2:05Let's go to the command line and see the AS_PATHS

2:09that we have as a result.

2:10So here on our 1 in 65111 where we have the prefix originated,

2:17if I do a show IP BGP, we see that from a path perspective

2:23it's empty.

2:24And that's exactly what we would expect.

2:26It's the origin of that prefix, so there is

2:29nothing in the AS_PATH there.

2:32And notice this I is the origin code, and that just,

2:36kind of, made its way all the way into this path column,

2:40because there is no path to report.

2:42But if we go down to someone that lives inside of 65222,

2:48how about the R4 device, and we do our show IP BGP,

2:53there's the prefix.

2:55And sure enough, it shows the path of 65111.

3:00So it does have that entry inside AS_PATH for that AS

3:06in which the prefix was originated.

3:09Perfect.

3:10And now, of course, let's go all the way over to R5, do our show

3:14IP BGP, and there is the complete AS_PATH

3:18that we expected to see.

3:20Notice on the right side, the AS of origin

3:24if you will, 65111 and then 65222 was pre-pended to that,

3:32put at the beginning of the AS_PATH

3:35and that's who we received this prefix from.

3:39And one of the fun things you can do with BGP

3:41is you can literally look at the global BGP table.

3:45This is with Looking Glass servers.

3:47If you do a Google search on BGP Looking Glass,

3:50you'll find plenty of options that

3:51will allow you to peer into the global BGP table.

3:55So I've done, so with this hurricane

3:57electric internet services Looking Glass,

4:00and notice it's taken my IP address

4:03and it's shown me where my subnet is available inside

4:08of the global BGP routing table.

4:11And look at the path.

4:12You can see that these folks have learned of my prefix

4:17from a source of 33363, and then they

4:22were given the prefix from the AS 7843.

4:25So this AS_PATH is a critical path attribute

4:31and now we can interpret it just fine.

4:35You just can't overlook the importance

4:37of well-known mandatory BGP attributes,

4:40and AS_PATH is one of those.

4:42We know there's Origin, AS-PATH, and we also

4:46know there's Next Hop as well known and mandatory.

4:50I hope you found this Nugget informative,

4:52and I'd like to thank you for viewing.

0:00It's really no surprise that a BGP prefix has

0:03an attribute called NEXT_HOP.

0:05After all, a router is going to need

0:07to know where to send traffic for that prefix.

0:11And the NEXT_HOP attribute fulfills this need.

0:14But what's interesting about it is,

0:16it does not work like our interior gateway protocols.

0:20Let's take a look at that fact in this Nugget.

0:23If we were thinking about an interior gateway protocol, when

0:26this device sends an update to its neighbor,

0:29the next hop would be this interface right here.

0:32And then of course, when this device sends it to this device,

0:35then the next hop would be here.

0:37And the next hop would be a hop-to-hop type of value.

0:41But that's not how our BGP protocol works.

0:45When we have eBGP and the prefix is sent,

0:49this router right here will see the next hop

0:52as the eBGP advertiser of that prefix.

0:56But this is going to be retaining this value as it

1:00sends it through the iBGP.

1:03So this is a unique characteristic.

1:06The next hop, as this router would see it,

1:09to that prefix is going to be way out here,

1:13the originator of that prefix from an AS perspective.

1:17And this can cause some interesting issues.

1:20Something else that's interesting

1:21is, with iBGP, it will be the interface of the iBGP prefix.

1:27So if this device right here originates some prefix

1:32and sends it via iBGP into this cloud,

1:35then this device would see that as the next hop, not

1:39this device.

1:41I know this may be a little confusing.

1:43Let's take a look at this on the command line.

1:46And let's see some interesting problems that

1:48can result from this behavior.

1:51If we look at the R1 device in our topology,

1:53this device is originating the prefix for the 1.1.1 network.

1:59And because it's originating that prefix,

2:01notice it has a Next Hop of quad 0.

2:04That would make sense, as it's the originator of the prefix.

2:08Now we're on our R2.

2:09This is an eBGP peer of that device.

2:12And notice the Next Hop is set to the R1 interface.

2:17This makes sense, even from an iGP perspective.

2:21But what's going to be interesting

2:23is this Next Hop value is going to be carried when it sends

2:27this entry to its iBGP peer.

2:31And sure enough, now we have a problem.

2:34Look at this.

2:36The prefix does show up on R3 with the Next Hop

2:41of that next autonomous system that it

2:43came from that Next Hop of 10.12.12.1.

2:47And notice, it is not considered a best path.

2:51This path isn't, this prefix, I should say,

2:54isn't making its way into the routing table.

2:58And that's because the Next Hop of 10.12.12.1 1

3:04is listed as inaccessible.

3:07This device, if we do a show ip route,

3:11has no route to the 10.12.12 network.

3:16So in order for this prefix to be established here,

3:20we would need to use a static route or some method

3:23to educate this device how to get to that next hop.

3:27Now, there is a little cheat we can apply,

3:30and this is a best practice.

3:32And that is to go to the R2 device

3:35and say that it should override that Next Hop value.

3:40So we'll go into this device and we'll say, router bgp 65.

3:45This is the 2222 autonomous system.

3:48And we'll say, look, on your neighborship to the 10.23.23.3

3:55device for Next Top set yourself as the Next Hop.

4:01That's it this little kind of Band-Aid for Next Top

4:05should take care of it.

4:07Let's go over to R3.

4:08And let's see if this kicked in right away.

4:10We'll do a show ip bgp.

4:14And no, nothing yet.

4:16So it's still not seeing that new Next Hop information.

4:21Let's force it very bluntly.

4:24We'll go, clear ip bgp asterisk, and we'll

4:29reset our BGP sessions.

4:32Now we'll go over to R3.

4:34We see that the sessions have reset.

4:36And we'll do a show ip bgp over there.

4:40And look.

4:40Now things have been updated.

4:43And now we're in good shape.

4:45If I do a show ip bgp, and we specify that prefix

4:50to get more information, we'll see

4:52that there is a best path available,

4:55and that the Next Hop is now 10.23.23.2.

5:01And that is the R2 device that said, use my Next Hop.

5:06We know how to get to that device.

5:09So now the prefix is being implemented

5:12as the path is perceived as reachable, which it is,

5:16of course.

5:17So when you're thinking about that important NEXT_HOP

5:20attribute in BGP, don't really think router to router.

5:25Think more autonomous system to autonomous system with it.

5:30And that will get your head clear on how this works.

5:33And it will also get you thinking

5:35about reachability issues that could result,

5:38as we saw in this Nugget, where some internal BGP device does

5:44not know how to get to the next hop,

5:46because it is a clear prefix entry that

5:49is way out of its autonomous system

5:52and is the entry point to the next autonomous system.

5:56Remember, AS-to-AS instead of router-to-router logic.

6:01I hope you found this Nugget informative.

6:03And I'd like to thank you for viewing.

0:00Now, let's deviate a little bit in our discussion

0:03of path attributes and border gateway protocol.

0:06One of the super interesting ones is weight.

0:10This attribute is so interesting because it

0:13is specific to Cisco.

0:15Now, Cisco is such a giant in the industry

0:19that many other vendors will recognize weight.

0:22But this attribute is so unique.

0:25Let's discuss it in depth here.

0:28Weight, it turns out, is a value that

0:30is assigned to our prefixes, and the first very unique thing

0:34about it is it only on a router, and this information does not

0:41get passed to any other router--

0:44interesting.

0:45So there is this weight attribute,

0:47but the devices are not advertising this weight.

0:51It's for local use only.

0:53It turns out the weight is a simple number from 0 to 65535.

1:01And the higher the weight value, the higher the preference.

1:06So a bigger weight here is better.

1:08I sure wish that was under my Weight Watchers rules.

1:11But anyways, something else that's interesting about weight

1:15is that when the prefix is locally generated,

1:20it will get a weight of 32768.

1:25Otherwise, the default weight is zero for a prefix.

1:30So before we look at this at the command line,

1:32let's think about how it might be used.

1:35Let's say this AS right here is advertising the 111 prefix

1:41and so is this AS.

1:44So we have the 111 prefix being advertised from here as well.

1:49So certainly, on a device down here in this topology,

1:52it has two potential paths to get to that prefix.

1:57Well, sure enough, the administrator of this device

2:01has this weight value that they could go in and manipulate

2:05for one of the prefixes.

2:07All they would need to do to influence the path decision--

2:11let's say that way is to set this prefix coming in from that

2:16direction--

2:17to a higher weight value.

2:19And now, they can easily override the routing decision.

2:23They can prefer the path very quickly

2:26on that device utilizing the weight value.

2:30We got to remember, though, that this is a local setting only

2:35and is not advertised to other peers.

2:37So you need to use weight very carefully.

2:41Let's confirm all this at the command line quickly.

2:44If we go to R1, and we do a show IP BGP,

2:49this is the originator of that 111 prefix.

2:54So just as we expected, the weight

2:56is 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,

3:07and we do show IP BGP, we see that the weight

3:12is set to zero as we indicated.

3:14This device didn't originate that prefix.

3:18It learned of that prefix from another device,

3:21and it installed it in the BGP table with that weight of 0.

3:26We could go in and manipulate that weight, of course,

3:30on this local device, but it is going

3:33to default to that zero value.

3:35The Cisco invention of BGP weight--

3:40an amazingly powerful way on a local device to give

3:44influence to one path over another.

3:47Key being, on that local device only,

3:50though, as weight, as we've learned,

3:52is not advertised to other peers.

3:55I hope you found this Nugget informative,

3:57and I'd like to thank you for viewing.

0:00It's so interesting to compare BGP to IGPs.

0:05We know that the IGP has a metric, that

0:09in the case of OSPF for example, is based on cost which

0:13is directly based on bandwidth.

0:14And this is the big path determinant.

0:16With BGP, there are many path attributes

0:20that a prefix can have.

0:22And sure enough, these all lend themselves to the BGP Best Path

0:27Selection Algorithm.

0:29Now, as you look at this complex path decision,

0:33you may immediately think, why does it

0:36have to be this complicated?

0:37It's this complicated because remember

0:40when we're dealing with something

0:41like the internet prefixes is ISP to ISP communications,

0:46we want there to be as many tuning

0:49knobs as possible for policy.

0:52We want to be able to control as much as possible

0:55how prefixes are being shared and preferred throughout such

1:00a large complex network.

1:02Now, notice that I have inside here this table the word Cisco.

1:08This is Cisco's look at the BGP best path selection process,

1:14and the vendor, Juniper, might do it slightly differently.

1:18In fact, in this Nugget, I'll show you

1:20how they would go about it.

1:21So the great news is, though, is there's

1:24going to be so many similarities on some of this stuff on how

1:30the vendor would do it.

1:31For instance, the shortest AS path decision

1:35would come before the lowest MED with both Cisco and Juniper

1:42and someone else that is implementing this technology.

1:46So there is going to be consistency there.

1:48Highest weight makes sense that it's a Cisco thing

1:52and is considered first.

1:53And it makes sense that Juniper wouldn't even recognize weight

1:57because they don't, and it's not in their best path selection.

2:01Now, the other important thing to realize

2:05is that there are tests that are going to be

2:07done before this even kicks in.

2:10We talked about how NEXT_HOP must be accessible,

2:16for instance, before one router would advertise

2:20that prefix to another router.

2:22So keep in mind that routes--

2:25prefixes-- may not even make it to this best path selection

2:29if they don't meet some criteria like a reachable NEXT_HOP.

2:33Once they do get to this point, though, the analysis

2:37starts from the top down.

2:39So the highest weight--

2:41if there is a difference in weight values,

2:44then that's going to be the preferred path.

2:46The highest local preference attribute-- if that's there,

2:50and there is a difference, then it would be used,

2:53and the algorithm doesn't have to look any farther.

2:57Notice that when we get down here,

3:01it's like almost random tiebreakers.

3:04You can really see that with the last gasp

3:07at picking a best path of multiple paths,

3:10and that's the lowest neighbor IP address.

3:14So if your neighbor has like 10.10.10.1,

3:17then it would be chosen that path as opposed to someone else

3:21that has like 172.16.

3:23So there has to be a selection of the very best path,

3:28and it'll use an arbitrary tiebreaker if it has to.

3:33If you happen to be studying for something like a Cisco

3:35certification exam, maybe you're studying

3:38for your CCIE certification in the route switch category,

3:43you pretty much have to memorize this as far

3:46as what's first what's second?

3:50Where's AS path determinant?

3:52Where's MED?

3:53And you'll see these students making flashcards

3:56to help them memorize the order and also memorize things

4:01like is a higher weight better or lower weight?

4:04Is a higher local preference better or lower

4:07local preference better?

4:09So these are really tried and true certification exams

4:13for Cisco that would come out of this chart.

4:16Now, I promised you we would take a look at the Juniper Best

4:19Path Selection algorithm for Border Gateway Protocol

4:23and here it is.

4:24We noticed that there is some proprietary things to Juniper--

4:27like Cisco had a proprietary weight value.

4:30Notice Juniper you could turn on something

4:32called the accumulated IGP value.

4:35So this would be the second thing that would be looked at.

4:38Notice when it comes to attributes that are well

4:41known like local preference, it comes before AS path

4:45which comes before lowest MED.

4:48So there is a consistency in those really big

4:51important parameters-- well worth noting.

4:54And then, sure enough, Juniper would

4:56do something like kind of panic at the end

4:58and use an arbitrary value like lowest neighbor

5:01address just as Cisco did.

5:04So with an interior gateway protocol like OSPF,

5:08it's pretty darn simple--

5:09lowest cost path wins.

5:11But with Border Gateway Protocol,

5:13there's many more policy controls

5:16and a much more sophisticated Best Path Selection Algorithm.

5:21In fact, it's called an algorithm

5:22because of its sophistication.

5:25I hope you found this Nugget informative,

5:27and I'd like to thank you for viewing.