For our discussion regarding border gateway protocol, let's use this topology.
So I have, I believe there's 10 routers here.
I've got R11, R12, R13, and over here I've got R21 and 22, and so forth and so
on.
I've also positioned these routers within these clouds, and these clouds
represent autonomous system.
So when we see the acronym AS, that stands for autonomous system.
So one service provider may be in charge of this autonomous system.
Let's say it's a autonomous system 10 and a different service provider is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's say it's a autonomous system 10 and a different service provider is
responsible for autonomous system 20,
and another one for autonomous system 30, and another one for autonomous system
40.
AS for short, and the autonomous systems have a number assigned to them.
And as part of that autonomous system, a service provider is very likely also
to have blocks of
internet reachable addresses associated or assigned to those service providers.
And then to share routing information using border gateway protocol,
the routers are going to be set up as BGP peers.
Now these BGP peers don't have to be directly connected. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now these BGP peers don't have to be directly connected.
For example, R12 and R13, although in this example, they're directly connected
via the 10, 12,
the 13 network, they don't have to be.
We could have, for example, R12 on the 10.20 network over here,
and R13 can be on the 10, 30 network over there.
But as long as they have reachability using TCP, and the well-known port for BG
P to set up the
connection is port 179.
So unlike an interior gateway routing protocol like OSPF or EIGRP,
where those two interior gateway routing protocols have their own layer for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
protocol,
BGP operates using layer for protocol TCP, and it connects to the well-known
port of 179,
which is where a BGP speaker is going to be listening for an incoming
connection.
And even though it's our topology for the lab environment, I have set up
directly connected peers.
They don't have to be.
As long as they reach ability to the IP addresses of the peer,
they can set up a BGP pairing of BGP neighborship.
Now regarding BGP peers that we set up, they're going to work with each other.
There are two types.
There's internal BGP peers and there's external BGP peers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's internal BGP peers and there's external BGP peers.
And here's the difference.
If we have two or three routers that are connected to each other,
and they're all in the same autonomous system.
For example, R12, peering with R13 and R13, peering with R11 and R11, peering
with R12.
Because they're all in the same autonomous system, each of these sessions that
are being represented by the green lines here,
those are going to be referred to as IBGP sessions, or the peers can be called
IBGP peers.
So these are in the green here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, those are internal BGP peers, because they're all within the same
autonomous system.
So here for IBGP peers, we'll put same AS.
So to finish that out, we'd have an IBGP neighborship here between R32 and R31,
because they're both in a autonomous system 30.
There'd be internal BGP neighborships between R42, R43 and R41.
As shown by these green lines, because all three of those routers are within
the same autonomous system,
autonomous system 40, and then appear in AS20 for R21 and R22. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
autonomous system 40, and then appear in AS20 for R21 and R22.
Once they're set up as BGP peers, that would be an example of an internal or IB
GP peering session,
because they're both in the same autonomous system.
Now let's compare and contrast that to an external BGP peer.
All it means is that the two routers that have the BGP peering setup,
they are in different autonomous systems than each other.
And there are several examples here in our topology between R11 and R31,
R11 and AS10, R31s in AS30, and as a result, that relationship would be
considered an external WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
considered an external
BGP neighborship, or they can be called external BGP peers.
It means the same thing.
Also between R31 and R41, because R31 is in AS30, and R41 is in AS40,
then also would be an external BGP neighborship.
And the same thing for R11 to R21, because R11 is in AS10, and R21 is in AS20.
And the same thing here between R21 and R42, because R21 is in the AS20,
and R42 is in AS40, because they're in different [garbled],
that would also be an external BGP neighborship. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that would also be an external BGP neighborship.
So the process would be after we configure our routers,
they form BGP sessions to their peers.
They start exchanging routing information with their peers.
And then once they have all that information, they can then decide,
based on all the information they have, which routes are the best,
and place those in the routing table.
So let's imagine that R11 and R21 have been set up as external BGP neighbors,
and R11 is sending an update, a routing update via BGP over to 21.
Let's say for example, that we have a route inside of a autonomous system 11,
let's say that route is 12.12.12.12, with a /32bit mask, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's say that route is 12.12.12.12, with a /32bit mask,
just as an example for discussion.
As that route inside of the autonomous system 10s,
and advertised from R11 to an external neighbor over here at R21,
the update would say, "Hey, here's the route 12.12.12.12.
It has a /32bit mask."
And when R21 receives that from the external BGP neighbor R11,
R21 is going to believe that the administrative distance for that route is 20,
which is pretty low. Compared to IGPs, like OSPF is 110, RIP is 120, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is pretty low. Compared to IGPs, like OSPF is 110, RIP is 120,
EIDRP internal is 90.
So that's a pretty low administrative distance from a routing table perspective
.
However, when a route is shared via internal BGP neighborship,
for example, the FAR 12, I've advertised that route over to R13 via BGP,
because that's an internal BGP neighborship.
R13 is going to assume that the administrative distance for that route
learned from an internal BGP neighbor is 200.
So here I'll put external AD of 20, and then for the internal, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here I'll put external AD of 20, and then for the internal,
meaning learn via IBGP, we'll put an AD of 200,
which is pretty darn high, actually.
So that's higher than most of our IGPs.
But that's the defaults where the ADs for routes learn via internal BGP peers
and routes learned from external BGP peers.
Now, in addition to advertising routing information,
which is often called NLRI, that's an acronym for network layer reachability
information,
there's also several attributes that are going to be shared as well.
And the reason I'm pointing out attributes right now is because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the reason I'm pointing out attributes right now is because
it becomes important if a router is receiving multiple routes,
it's going to be using some of these attributes to decide which route it should
use as the best route.
Some of those attributes include the AS path.
So, for example, when R1s advertising the route from 12, 12, 12, 12, which came
from AS 10,
the attribute of AS path would include 10 to indicate which autonomous system
is been stored.
And then when R21 is advertising that down to, for example,
R 42 down here in the time system 40, as far as the attribute is shared down WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R 42 down here in the time system 40, as far as the attribute is shared down
here,
it would say, "Hey, this was sourced in AS 10.
It's also now gone to AS 20."
So, as that route is being advertised down here,
the network layer reachability information will be 12.12.12.12 still,
they slash 32, if that's the actual network.
And the AS path attribute would include 10 and 20.
The two AS is a two-tomah systems that that routing information has passed
through.
Ever that same route, as that's being advertised over here,
throughout would still be 12, 12, 12, 12, with this slash 32, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
throughout would still be 12, 12, 12, 12, with this slash 32,
but this time the AS path attribute would include 10 where it was sourced
and 20 where it went through.
And now because it went through 40, it would include that as well.
And that would be part of the advertised
a autonomous system path attribute that's being shared in combination with that
route via BGP and BGP updates.
So, let me clear off a little room and let's talk about some decisions that a B
GP-speaking router is going to make
if it has two or more sources that it's learning the same route from.
Because for example, when R11 is advertising that same 12, 12, 12, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because for example, when R11 is advertising that same 12, 12, 12,
network down to R31, there's the route itself
and because R1 is advertising that down to R31.
And as R11 advertised that, it's going to indicate that the AS path for this
advertisement
only includes a ton of system 10 where it was sourced from.
So, this router here R31, when it receives the routing information,
we're getting the 12, 12, 12, 12 network and it learns it from R11 and it also
learns it from R41.
It's got to make a decision, we're going to its routing table,
regarding which route it's going to use. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
regarding which route it's going to use.
If it needs to reach that, destination is going to go this way up through R11,
or is it going to go this way over here to R41.
So, regarding path selection, it can use that attribute AS path as part of the
calculation.
So, when a router is deciding regarding path selection, the shortest AS path is
going to be preferred.
Now, that's not the only criteria regarding selecting the best route,
and that's also why I didn't put it up here at the top,
but it is one of the attributes.
So, in this case, if all other settings were equal,
R31 would say, "Oh, the AS path to get the 12, 12, 12, 12 is 10 here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R31 would say, "Oh, the AS path to get the 12, 12, 12, 12 is 10 here,
and it's 10, 20, 40 going through R41."
And as a result, in this example here, the shortest AS path would be considered
the best route,
and that's the route that would be put in the routing table,
and that's when R31 would use going up to R11,
based on the shortest AS path with 10 being less than 10, 20, 40.
However, that is not the actual very first thing it looks at,
when R31 is trying to make a decision on what is the best path to get to 12, 12
, 12, 12.
One of the items that's considered first before the shortest AS path is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of the items that's considered first before the shortest AS path is the
weight.
Now, weight is Cisco proprietary.
So, if you're working with other vendors,
they may not, their gear may not support weight,
but in a Cisco environment, weight is the first consideration,
when a router is making a decision regarding path selection,
the higher the weight, the bigger the number, the better.
So, if R31 associated the route that came in from R41 with a weight of 105,
and it associated the route that came in from R11 for that 12, 12, 12 network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it associated the route that came in from R11 for that 12, 12, 12 network,
as 102, the higher the weight would be better.
And as a result, R31 would choose the path based on the route that had the
highest weight.
Now, by default, the weights for the routes that come in are all the same.
Now, another item that's looked at is called local preference.
And that's used within an autonomous system.
So, for example, let's take R43 down here.
If it has a route that it's learned from R42 and also learned it from R41,
inside the autonomous system,
the route that's associated with the greatest or largest local preference would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the route that's associated with the greatest or largest local preference would
be used.
So, if R42 is advertising a route,
and R43 thought that the local preference for that route was, for example, 105,
and R41 was advertising the same route, and R43 associated that route with a
local preference of 103,
the larger local preference would be preferred.
And that's again within the autonomous system.
And one other item that Router is going to consider before it looks at the
length
of the autonomous system paths is, did I source this network myself?
Another way of saying that is, is the next top, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Another way of saying that is, is the next top,
which is also part of the attribute that they're being sent,
is the next top for that route, 0.0.0.0.
Meaning, let's imagine R22 is advertising its loopback of 22.22.22.22, with a
32-bit mask.
As part of the attributes in the BGP table here in R2,
it's going to have a next top of 0.0.0.0, effectively saying, "Hey,
I'm the person who injected this route or advertised this route inside of BGP."
So, if there was another route for 22, 22, 22, 22,
that was being advertised that came into R21 here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that was being advertised that came into R21 here,
and then R21 advertised it with the next top of itself.
So, it said the next top is 10.21.22.21.
Now, R2 has two routes that it knows about.
One with the next top of the GIGG 002 here from R21,
and one with the next top of 0.0.0.0.
And from the decision making process,
A route that has the next top of 0.0.0 is going to be identified as the best
path.
And then we have the shortest AS path as our fourth position right there.
And just to reinforce that with our topology, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And just to reinforce that with our topology,
let's imagine once again that we're advertising this network 12, 12, 12, 12,
and that is being shared here.
And then R11 is advertising here and down here.
And R31 is advertising here,
and R41 is advertising it over to R42 via IBGP,
and then R42 is advertising it up here to R21.
And then both those routes will be advertised down here to R22.
So, as R22 looks at that,
if they have the same exact weight, that's the tie,
and the local preference is the same for both.
And the next hop is not 0.0.0.0, meaning R2 didn't originate that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the next hop is not 0.0.0.0, meaning R2 didn't originate that.
Then we get to the AS path attribute.
And so the one coming in from here would have an AS path attribute of 10.
And the one coming in from over here would have 10, 30, 40.
Because that's the AS path that it went through as that route was being propag
ated
and advertised up here to R21.
And so as R22, and as well as R21,
looking at both those routes,
the one that's going to be better based on this shortest AS path,
is one that just had to go through AS 10 only, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is one that just had to go through AS 10 only,
and the one that didn't have to go through three.
Because 10 is less than or shorter than 10, 30, 40.
Now, in addition to these four path selection parameters,
there's actually a whole bunch more.
But for our discussion in this course and in this skill,
we're going to go ahead and just consider those first four
as the primary ones that we'd want to look at.
So as all the routes are propagated and shared,
they're going to be put on each of the routers into a IBGP table.
You can also refer to that as a rib, a routing information base.
And think of the BGP table as everything we've learned. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And think of the BGP table as everything we've learned.
So over here in R22,
we'd know about the 12 12 12 network,
learned from a couple of different sources,
and any other routes that have been advertised or shared via BGP.
But that doesn't mean that all those routes just automatically
make it into the winners table.
And when I talk about the winners table,
I'm talking about the routing table on a Cisco router.
That's the actual routing table that's used.
So for example, R22,
if it has learned about the 12 12 12 network,
a couple different ways,
it's going to have one of those,
and it's going to put that in the winners table and the routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it's going to put that in the winners table and the routing table.
And then that should show up as a BGP learned route.
So R22 could go ahead and start using that route
as it forwards real packets.
I also want to point out that there's a couple of different ways
of configuring BGP.
So there's the traditional BGP,
and there's also multi protocol.
So in this skill and in this set of videos,
we're going to focus on the traditional BGP
where it supports IPv4 by default.
And with multi protocol BGP, it breaks it out into address families.
For example, we could have an address family for IPv4 and IPv6 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For example, we could have an address family for IPv4 and IPv6
and also for multicast and for other VPN routes and more.
And going forward in this set of videos,
we're going to focus on traditional BGP.
And then as far as address families go,
we'll go ahead and save that for another discussion
in a separate course in an RC or something equivalent.
And before we leave the overview,
let me also chat with you about one other consideration
that's a really good idea, especially if we are inside
of our own autonomous system.
And that is to leverage loopbacks.
When we set up our pierings between, for example, R13 and R12, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When we set up our pierings between, for example, R13 and R12,
which would be an internal BGP neighborship,
we could say to R12, "Hey, your pier is at 10.12.13.13."
That's this interface address.
And on R13, we could say, "Hey, your pier is at 10.12.13.12."
And that's all well and good, but what if one of these interfaces fails?
If that interface fails, meaning it goes down or has a problem,
and that interface IP address is not reachable,
we're going to lose that BGP neighborship between R13 and R12.
Unless we did something creative like using a loopback. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Unless we did something creative like using a loopback.
So by using a loopback, and in each of these autonomous systems,
there is an IGP already running.
So all the routers via OSPF or whatever IGP they're using,
they know how to reach all the internal networks
based on the IGP that's in place.
So if that was true, and we had this router
with the loopback address of 12.12.12.12,
if that's the loopback zero address,
and over here on R13, if it's loopback zero,
is 13.13.13.13.13.
Then what we could do is when we set the pairings, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then what we could do is when we set the pairings,
we could say, "You know what?
I want to pier with my pier here at this IP address."
And on R13, we could say, "I want to pier with the loopback target address here
."
And that way, even if we lose these interfaces,
if we still have another path through the network to get to our pier,
we won't lose the BGP neighborship.
And that's one of the benefits of using a loopback for peering.
So if we do that, we have to specify on the routers,
that, "Hey, here's my pier, and I want to source this BGP session
from my loopback address as we target the other devices loopback address." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from my loopback address as we target the other devices loopback address."
So with that in mind, in the next video,
let's go ahead and begin our configuration
of Border Gateway Protocol.
I'll see you in the next video in just a moment.