|
0:00:13
|
Welcome back everybody to CCIE InterNetwork Expert Routing and Switching Advanced Technologies class.
|
|
0:00:19
|
In today's session, we're gonna be talking about Border Gateway Protocol Version 4, or BGP.
|
|
0:00:25
|
First, we're gonna start some of the general theory behind BGP.
|
|
0:00:29
|
How we establish peerings,
|
|
0:00:31
|
the different types of peerings, differences between IBGP, EBGP.
|
|
0:00:36
|
Some of the specifics about how we process IBGP updates different than EBGP.
|
|
0:00:41
|
We'll also take a lot at a lot of verifications and configuration
|
|
0:00:46
|
for establishing the peerings.
|
|
0:00:48
|
Different types or designs with route reflection confederation.
|
|
0:00:51
|
And then later this afternoon, we're gonna get into some more of the advanced designs.
|
|
0:00:55
|
How the BGP best path selection process works,
|
|
0:00:58
|
how can we do traffic engineering with BGP,
|
|
0:01:01
|
and then, additional new enhancements that are available in the more recent IOS versions.
|
|
0:01:07
|
So, to start, as we know, BGP is an open standards-based protocol.
|
|
0:01:11
|
The main definition is available in RFC 4271, which is BGP Version 4.
|
|
0:01:17
|
So, for any real detailed information that you want to get on BGP,
|
|
0:01:22
|
things about the actual packet formats,
|
|
0:01:24
|
how do the open messages work, how do the updates messages work.
|
|
0:01:28
|
Then, that's definitely gonna be the best resource for that very low level type information.
|
|
0:01:34
|
So, in today's discussion, we're not gonna get into things like the BGP peerings, state machine, or the...
|
|
0:01:40
|
different updates state machines.
|
|
0:01:42
|
A lot of that is gonna be outside the scope of our configuration for BGP.
|
|
0:01:46
|
It's gonna be pings that are just going on behind the scenes.
|
|
0:01:50
|
But if for some reason, you do need to reference that,
|
|
0:01:52
|
then, generally, the RFC is gonna be the best place to do that.
|
|
0:01:56
|
Now, for other resources that are available for BGP,
|
|
0:02:01
|
there's a lot of good information on Cisco's website about BGP.
|
|
0:02:04
|
If you do to the Main Documentation page,
|
|
0:02:08
|
then, down to Technology,
|
|
0:02:11
|
IP,
|
|
0:02:12
|
IP Routing,
|
|
0:02:14
|
and BGP,
|
|
0:02:17
|
you'll see, the information located here...
|
|
0:02:19
|
Most of it, you will not have access to when you get to the actual lab exam,
|
|
0:02:24
|
but this is definitely some good information you can go through it during your normal preparation process.
|
|
0:02:30
|
Like the BGP frequently asked questions,
|
|
0:02:32
|
I definitely would recommend to look through that.
|
|
0:02:35
|
One that's very important we're gonna be referencing today is the BGP best path selection algorithm,
|
|
0:02:40
|
which has a lot of minor points beyond things like the AS path or local preference
|
|
0:02:46
|
that we may need to look at...
|
|
0:02:48
|
to see why is router 2's and 1's path over another.
|
|
0:02:53
|
And other links to things like the RFCs,
|
|
0:02:56
|
and different design documents you'll see here located under this technology support.
|
|
0:03:01
|
Now, as for the actual configuration documentation and the command references,
|
|
0:03:06
|
we'll be looking at the 12.4T Configuration Guide,
|
|
0:03:10
|
and the 12.4T Command Reference for BGP commands and for the BGP Configuration Guide.
|
|
0:03:18
|
Now, as you can see, from the page here in the Command Reference,
|
|
0:03:22
|
BGP commands are broken down to a number of different pages.
|
|
0:03:26
|
So, it basically means that there's lots and lots of features in this protocol.
|
|
0:03:31
|
So, many more than RIP Version 2 or EIGRP,
|
|
0:03:35
|
or even more than OSPF Version 2.
|
|
0:03:39
|
We'll see that not all of the features of BGP are gonna be within our scope
|
|
0:03:43
|
of the CCIE Routing and Switching lab exam.
|
|
0:03:46
|
We will talk about BGP again later when we get to separate topics like IPv4 multicast,
|
|
0:03:52
|
IPv6 unicast routing, and then also for Layer 3 MPLS VPNs.
|
|
0:03:56
|
But there's some topic that would be reserved for service provider
|
|
0:04:00
|
CCIE track that we are not gonna be discussing within the protocol.
|
|
0:04:06
|
If we look at the Configuration Guides for BGP,
|
|
0:04:11
|
this would be down under IP, then, BGP Configuration Guide.
|
|
0:04:17
|
You see that it's broken down to a lot of different sub-topics here,
|
|
0:04:21
|
where the main ones that we would want to reference
|
|
0:04:23
|
would be configuring the basic BGP network
|
|
0:04:26
|
connecting to an external service provider using EBGP,
|
|
0:04:30
|
and then, configuring BGP neighbor session options.
|
|
0:04:34
|
So here, in things like the...
|
|
0:04:37
|
configuring the basic BGP network, this talks about how do you do route aggregation,
|
|
0:04:41
|
how do we set up BGP peer groups,
|
|
0:04:45
|
how do we do different templates for the peers.
|
|
0:04:48
|
So, things that are gonna relate to the general
|
|
0:04:51
|
peering establishment and just getting the basic BGP process working.
|
|
0:04:55
|
Once the peerings are up,
|
|
0:04:57
|
then, the vast majority of work in BGP
|
|
0:05:00
|
is generally related to traffic engineering and applying a policy
|
|
0:05:05
|
that we're trying to implement for either our outbound traffic flows or our inbound traffic flows.
|
|
0:05:11
|
Majority of this is gonna be documented under
|
|
0:05:13
|
this section that is connecting the service provider using external BGP.
|
|
0:05:17
|
So, this is where we talk about how do the BGP communities work,
|
|
0:05:21
|
how do advanced features like the outbound route filtering,
|
|
0:05:25
|
or the BGP ORF process work,
|
|
0:05:27
|
and then also, how do we use the different attributes in order to affect the BGP best path selection.
|
|
0:05:32
|
So, you'll see, there'll be examples here of how do we change the inbound path selection,
|
|
0:05:38
|
which basically means for traffic that is coming in to our network from the service provider.
|
|
0:05:42
|
How do we affect the outbound path selection,
|
|
0:05:45
|
which would be the traffic that our clients are originating
|
|
0:05:48
|
as it goes out to the global BGP network.
|
|
0:05:52
|
Now, ideally, a lot of this, you should not need to reference when you get to the actual lab exam.
|
|
0:05:57
|
The vast majority of the BGP syntax and the implement logic,
|
|
0:06:01
|
you should know off the top of your head.
|
|
0:06:03
|
But for some of these minor features, maybe like the...
|
|
0:06:07
|
outbound route filtering, or other minor features in BGP.
|
|
0:06:11
|
You don't necessarily need to memorize the syntax for that.
|
|
0:06:15
|
As long as you know what the features are, and where to reference them in the documentation,
|
|
0:06:19
|
you should be able to take a lot of the examples here,
|
|
0:06:22
|
and then, modify them to fit your particular requirements.
|
|
0:06:26
|
But we'll see, a lot of these different examples we'll go through,
|
|
0:06:30
|
we will be referencing the command reference a lot
|
|
0:06:32
|
to see what are the different options for the commands and what are the default values.
|
|
0:06:38
|
Now, BGP is considered a path vector routing protocol,
|
|
0:06:43
|
because as opposed to EIGRP, which is considered distance vector or OSPF that is link state,
|
|
0:06:49
|
the majority of the IGPs are making the decision based on simply one value,
|
|
0:06:54
|
which is the metric in order to reach the destination.
|
|
0:06:58
|
Now, we know that with protocols like EIGRP,
|
|
0:07:01
|
this metric value is actually made up of multiple sub-values
|
|
0:07:04
|
like the bandwidth, the delay, the load reliability.
|
|
0:07:07
|
But in the end, we're simply choosing what is the lowest path end-to-end
|
|
0:07:12
|
in order to reach a particular destination.
|
|
0:07:15
|
Now, the problem with that,
|
|
0:07:18
|
based on the simplicity that IGP is making the decision on,
|
|
0:07:22
|
it makes it very hard to implement a specific routing policy
|
|
0:07:26
|
for different type of destinations.
|
|
0:07:29
|
Whereas with OSPF for example,
|
|
0:07:32
|
the OSPF cost value is not a function of the route itself,
|
|
0:07:36
|
but it's a function of the links that we used in order to get
|
|
0:07:40
|
to that destination route, or that destination prefix.
|
|
0:07:44
|
So essentially, what this means in an OSPF network,
|
|
0:07:47
|
if we were to modify the cost value that we used to reach one particular destination,
|
|
0:07:52
|
the vast majority of the time it's going to implement to the cost of a lot of other destinations.
|
|
0:07:58
|
Whereas with BGP,
|
|
0:08:00
|
this protocol was originally implemented in policy in mind,
|
|
0:08:04
|
where the individual attributes on a per-route basis
|
|
0:08:08
|
are gonna be used to determine how we route to a particular destination
|
|
0:08:12
|
based on the individual attributes.
|
|
0:08:16
|
So, this means that we could change attributes like local preference,
|
|
0:08:19
|
or the AS path, or the origin code on a per-prefix basis
|
|
0:08:23
|
in order to change our routing policy for either the outbound traffic or the inbound traffic.
|
|
0:08:31
|
Now, another key feature for BGP
|
|
0:08:34
|
is it support for variably length subnet masking and summarization.
|
|
0:08:38
|
Because as we know, in today's networks, as the size of the Internet grows,
|
|
0:08:42
|
it also means that the size of the global BGP table is growing.
|
|
0:08:46
|
So, if we were to look at one of the public route servers,
|
|
0:08:50
|
and most of these that you can get to if you connect to...
|
|
0:08:56
|
the domain name route-server dot the provider's name,
|
|
0:09:01
|
so in this case, we have Global Crossing in Europe,
|
|
0:09:04
|
or Hurricane Electric, ATNT.
|
|
0:09:08
|
So, these particular...
|
|
0:09:10
|
route servers are basically just routers
|
|
0:09:13
|
are used for us to check the policy
|
|
0:09:16
|
that we're trying to apply to our outbound routing advertisements on to the global Internet.
|
|
0:09:23
|
So, from any of these devices...
|
|
0:09:25
|
in the public Internet, if we were to look at the Show IP BGP Summary,
|
|
0:09:30
|
it's gonna tell us on average what's the current size of the global BPG table.
|
|
0:09:35
|
So, for this particular router, this is part of the ATNT's network.
|
|
0:09:40
|
It says right now, they have 349,000 network entries,
|
|
0:09:45
|
but there are over 6.4 million paths in order to reach them.
|
|
0:09:52
|
So, it's essentially saying, "We have almost 350,000 unique prefixes,
|
|
0:09:57
|
but there's almost 6 and a half million routes to get there."
|
|
0:10:02
|
So, in order to make sure that as the size of the network grows,
|
|
0:10:07
|
it's not a linear function of the size of the BGP table,
|
|
0:10:11
|
aggregation and the use of variably length subnet masking is gonna be a very key point.
|
|
0:10:16
|
So, if we were to look at the actual...
|
|
0:10:18
|
information that's in any of these tables, the Show IP BGP Output,
|
|
0:10:23
|
we should generally see that the routing information here
|
|
0:10:25
|
is probably not gonna go beyond maybe /22 or so
|
|
0:10:30
|
depending on what provider they're looking at their view from.
|
|
0:10:36
|
So, we don't want end customers advertising all /32 host routes into the BGP network,
|
|
0:10:41
|
because it's gonna make the size of the routing table unmanageable,
|
|
0:10:45
|
and it's simply gonna take too may resources in order to do the best path selection process.
|
|
0:10:51
|
So, we'll see, using...
|
|
0:10:53
|
the summarization for BGP is definitely a very important design point.
|
|
0:10:58
|
And BGP gives us a lot of flexibility
|
|
0:11:02
|
as to the different attributes we can set, and the different links of aggregates that we can generate,
|
|
0:11:08
|
and the attributes that are going to belong to the individual subnets of the summaries.
|
|
0:11:14
|
So, we'll see, depending on...
|
|
0:11:16
|
what the actual design goal we're trying to get to,
|
|
0:11:18
|
there are maybe 10 or 20 different ways that we can actually implement that with BGP.
|
|
0:11:24
|
So, part of our goal
|
|
0:11:26
|
today in our BGP lessons is to figure out
|
|
0:11:29
|
basically what are all the possible ways in order to get to the same end result.
|
|
0:11:35
|
Because within the scope of the lab exam, we may have a question that says...
|
|
0:11:38
|
"We want you to do this for BGP, but don't use configuration commands A, B, or C."
|
|
0:11:47
|
So, in that case, we would need to figure out what are the other options left over for us
|
|
0:11:50
|
that we could come up with an implementation that is gonna meet those very specific requirements.
|
|
0:11:57
|
Now, in the real world implementation,
|
|
0:11:59
|
a lot of the application for BGP is just gonna be a personal preference
|
|
0:12:04
|
of the operator that's actually doing the implementation.
|
|
0:12:08
|
We'll see that some solutions may be more scalable than others.
|
|
0:12:12
|
And from an administration point of view, it may make more sense to choose one design for BGP versus another one
|
|
0:12:19
|
depending on if we are a service provider that has tens of hundreds of thousands of customers running BGP,
|
|
0:12:26
|
where whether we are just an end network,
|
|
0:12:29
|
a stub network that has maybe just one or two upstream BGP peers.
|
|
0:12:36
|
Now, another key point we'll talk about with BGP
|
|
0:12:40
|
is its extensibility,
|
|
0:12:42
|
which means that the application of BGP itself can be used for more than just IP Version 4 unicast routing.
|
|
0:12:50
|
Now, today's discussion of BGP is mainly gonna focus on IPv4 unicast.
|
|
0:12:55
|
When we get to the different topic domains, like multicast, IPv6, and MPLS,
|
|
0:12:59
|
we're also gonna revisit BGP
|
|
0:13:02
|
to see what are the specific implementations of BGP that relate to those specific technologies.
|
|
0:13:09
|
Now, the first thing that we need to understand when we're getting into the BGP implementation
|
|
0:13:14
|
is how the autonomous system numbering works
|
|
0:13:17
|
so we can identify where routes are originated from
|
|
0:13:20
|
as they're advertises out onto the global Internet.
|
|
0:13:24
|
So, we see here the official of autonomous system per the BGP RFC.
|
|
0:13:30
|
Where in general, it just means that the autonomous system
|
|
0:13:33
|
is gonna be the devices that are under the same control
|
|
0:13:36
|
of a group of engineers, or a particular business unit.
|
|
0:13:42
|
So, in a real world implementation,
|
|
0:13:45
|
you may see that a network has just one autonomous system for all of their connections in the Internet,
|
|
0:13:50
|
or if the BGP policy is very complex,
|
|
0:13:53
|
or the network is grown to acquire additional business units over the years,
|
|
0:13:58
|
then, one particular network may have multiple autonomous systems.
|
|
0:14:03
|
But the key point about the autonomous system
|
|
0:14:05
|
is that in general, a routing policy will apply to the autonomous system as a whole
|
|
0:14:13
|
where the policy for AS 1 is gonna be different for the policy from AS 2.
|
|
0:14:20
|
Now, also a key point here, it says in the definition that the...
|
|
0:14:24
|
the AS's are defined by a signal technical administration of the routers that are using an Interior Gateway Protocol
|
|
0:14:31
|
and common metrics to determine how to route packets within the AS.
|
|
0:14:37
|
So, we'll see a key point about BGP design
|
|
0:14:40
|
is that routers within the same autonomous system
|
|
0:14:43
|
have to have IGP reachability to each other first,
|
|
0:14:47
|
because in reality, BGP is not a routing protocol per se.
|
|
0:14:52
|
It's an application that is mainly designed to do two things:
|
|
0:14:57
|
it's designed to advertise an IP prefix and a next hop value associated with that prefix.
|
|
0:15:05
|
Now, that would be considered just the most simplistic explanation of BGP.
|
|
0:15:10
|
As we know, there's really more stuff that goes on behind the scenes.
|
|
0:15:13
|
We could use it for IPv6, we could use it for multicast.
|
|
0:15:16
|
But for the original design of BGP,
|
|
0:15:20
|
it's main job is just those two things:
|
|
0:15:22
|
to advertise IP prefix information
|
|
0:15:24
|
and the next hop value that's associated in order to reach those prefixes.
|
|
0:15:29
|
We'll see, the design issue we'll run into
|
|
0:15:32
|
is that the next hop value that BGP reports,
|
|
0:15:37
|
that must be then recursed through some other underlying IGP routing protocol.
|
|
0:15:44
|
So essentially, it's very impractical to design a network that is routing just on BGP alone.
|
|
0:15:50
|
Generally, BGP would be relying to OSPF, or EIGRP,
|
|
0:15:54
|
or IS-IS to figure out, how do we route traffic within the autonomous system.
|
|
0:15:59
|
Then, we're mainly using BGP to figure out what are the destinations
|
|
0:16:02
|
outside of our network that we are trying to reach.
|
|
0:16:10
|
Now, the AS numbers themselves, just like IPv4, or IPv6
|
|
0:16:14
|
addresses that are globally routable on the Internet,
|
|
0:16:17
|
those are gonna be assigned by the Internet Assigned Numbers Authority, or the IANA.
|
|
0:16:22
|
So, if you wanna get more information about the policy behind obtaining an autonomous system,
|
|
0:16:27
|
you can go to the IANA.org website.
|
|
0:16:32
|
Now, the one key thing to notice
|
|
0:16:34
|
about the IANA allocation
|
|
0:16:38
|
is that recently, there has been a change
|
|
0:16:40
|
as to the format that the autonomous system numbers use.
|
|
0:16:45
|
Previously,
|
|
0:16:47
|
for about the past 15 or 20 years even,
|
|
0:16:51
|
BGP traditionally used a 2-byte field that was used to describe the autonomous system number.
|
|
0:16:56
|
Where the values for a 2-byte field would be decimal zero through 65535.
|
|
0:17:03
|
Autonomous system zero was never allocated.
|
|
0:17:07
|
So, the public AS numbers run from 1 to 64511,
|
|
0:17:12
|
where the last 1024 addresses
|
|
0:17:15
|
that go from 64512 up to 65535,
|
|
0:17:19
|
those were considered reserved or private addresses.
|
|
0:17:23
|
So, similar to how the RFC 1918 addresses defines the 10 network,
|
|
0:17:28
|
the 17216, and the 192168 addresses.
|
|
0:17:33
|
So, if you look at the global BGP table,
|
|
0:17:36
|
you shouldn't see anything that goes from 62512 up to 65535.
|
|
0:17:43
|
Now, the problem with this though
|
|
0:17:45
|
is that it means there can't be more than about 64000,65000 networks that are attached to the Internet
|
|
0:17:50
|
that are actually running public BGP.
|
|
0:17:55
|
Up to this point, essentially, all 2 byte autonomous system numbers have been allocated.
|
|
0:18:00
|
So, there's really no space left over
|
|
0:18:03
|
for these 2-byte fields. There's more than 65,000 people running BGP now.
|
|
0:18:08
|
So, in the past couple of years, they have now migrated to a 4-byte autonomous system
|
|
0:18:14
|
that is now supported as of IOS Version 12.4(24)T.
|
|
0:18:19
|
So, we'll see in our implementation examples today,
|
|
0:18:22
|
depending on what the particular IOS version that we're using is,
|
|
0:18:26
|
some of the processes will support just the legacy 2-byte AS.
|
|
0:18:30
|
Some of them will support the new 4-byte autonomous system.
|
|
0:18:34
|
And you can see, there's a new RFC 4893
|
|
0:18:37
|
that defines exactly how the 4-byte autonomous system numbers should be allocated.
|
|
0:18:44
|
Now, the reason that this is a key point that I'm mentioning upfront before we get to other operations of BGP
|
|
0:18:50
|
is that since not all versions of code for BGP actually support the 4 byte AS numbers so far,
|
|
0:18:58
|
it means that there has to be a backwards compatibility built into the protocol
|
|
0:19:03
|
for the new BGP speakers versus the "old BGP speakers".
|
|
0:19:09
|
Where the new BGP speakers would be negotiating
|
|
0:19:12
|
during the BGP capability exchange
|
|
0:19:15
|
that they will support the 4 byte autonomous system numbers.
|
|
0:19:20
|
For the old BGP speakers,
|
|
0:19:23
|
when they receive the capability request from a new BGP speaker,
|
|
0:19:27
|
since they don't understand the 4 byte format,
|
|
0:19:29
|
they're simply going to say, "I don't support that capability."
|
|
0:19:34
|
This means the devices that do support the new 4 byte AS's,
|
|
0:19:38
|
they need to figure out some sort of backwards compatibility
|
|
0:19:41
|
so we can still encode the autonomous system numbers inside the AS path information.
|
|
0:19:47
|
And we'll see, the way that this is done
|
|
0:19:49
|
is by the reserved AS number 23456.
|
|
0:19:54
|
So, from the perspective of the IOS versions that do not support the 4 byte AS numbers,
|
|
0:20:00
|
they will see, everyone that has the 4 byte value
|
|
0:20:03
|
represented as the AS numbers 23456.
|
|
0:20:09
|
Now, this doesn't mean that the AS path information is going to be lost
|
|
0:20:13
|
when we're going to the older BGP speakers,
|
|
0:20:16
|
because there's two new optional transitive attributes
|
|
0:20:20
|
that are defined by that particular RFC
|
|
0:20:23
|
that defines the 4 byte AS's.
|
|
0:20:26
|
Specifically, these are the AS 4 aggregator and the AS 4 path.
|
|
0:20:31
|
We'll see that for devices that do support the new notation,
|
|
0:20:35
|
which is sometimes called the AS.notation,
|
|
0:20:40
|
they will encode the As path information in the new optional attributes.
|
|
0:20:46
|
Then, in the BGP set up message,
|
|
0:20:49
|
which is the open message and then the actual updates,
|
|
0:20:52
|
they're gonna replace their autonomous system number with 23456.
|
|
0:20:58
|
So, we'll see that this is gonna have some implementation impact
|
|
0:21:03
|
for the devices that are still running the old code.
|
|
0:21:07
|
Now, within the scope of the lab exam,
|
|
0:21:09
|
most of the regular routers should be running 12.4T
|
|
0:21:13
|
whether they're actually gonna be running that particular train 12.4(24)T or later,
|
|
0:21:18
|
really, there's no way for us to predict whether that's gonna be the case.
|
|
0:21:23
|
But we know at a minimum that the Catalyst-IOS is not going to support this.
|
|
0:21:29
|
So, the 3560s or the 3550s or the other platforms around that hardware range,
|
|
0:21:35
|
they're not gonna be supporting the 4 byte AS's.
|
|
0:21:38
|
So, this means, if we have one of the switches
|
|
0:21:41
|
that's doing a BGP peering to someone that is running a 4 byte AS number,
|
|
0:21:46
|
we need to understand how this backwards compatibility works.
|
|
0:21:50
|
So, once we get into our actual implementation examples,
|
|
0:21:53
|
I'll show how the backwards compatibility works,
|
|
0:21:56
|
and how the AS number 23456 is actually used to encode the new format of the autonomous systems.
|
|
0:22:05
|
Now, the actual logical process of BGP
|
|
0:22:08
|
for establishing the neighbors, exchanging the updates, and then you're actually routing the traffic
|
|
0:22:13
|
is the same type of logic that we used for our IGP establishment.
|
|
0:22:18
|
So for example, in both EIGRP and OSPF,
|
|
0:22:22
|
our first step would be to figure out who are the neighbors
|
|
0:22:25
|
on our connected links that we want to run OSPF or EIGRP with.
|
|
0:22:30
|
Once we find the neighbors, we go through an adjacency negotiation
|
|
0:22:34
|
where we talk about different attributes like the OSPF area number,
|
|
0:22:38
|
the authentication, the OSPF stub flags.
|
|
0:22:41
|
Once the neighbor relationship comes up and we form the adjacency,
|
|
0:22:45
|
then, we actually exchange the updates and can do the path selection.
|
|
0:22:48
|
So, we have the same type of logic here where with BGP,
|
|
0:22:52
|
first step would be to figure out how do we establish the peerings.
|
|
0:22:58
|
Now, some of the key differences we'll see that are
|
|
0:23:00
|
not the same between IGP and BGP
|
|
0:23:04
|
is that first and foremost, BGP does not have it's own transport protocol.
|
|
0:23:09
|
Whereas OSPF uses IP protocol number 89,
|
|
0:23:13
|
EIGRP uses IP protocol number 88,
|
|
0:23:16
|
BGP is gonna run on top op TCP.
|
|
0:23:20
|
Now, we'll see that this implies that the BGP neighbors
|
|
0:23:23
|
would have to have IGP reachability to each other
|
|
0:23:27
|
before they could then establish the BGP session.
|
|
0:23:31
|
We'll also see that since BGP is a standard TCP application
|
|
0:23:36
|
that the normal client server rules of TCP are going to apply.
|
|
0:23:42
|
We'll also see that BGP has different types of neighbors
|
|
0:23:45
|
whether these are IBGP neighbors, EBGP neighbors,
|
|
0:23:48
|
confederation EBGP neighbors, route reflector clients, route reflector non-clients.
|
|
0:23:53
|
The different types of BGP peers are gonna control how updates are processed
|
|
0:23:59
|
and how the best path selection is gonna work
|
|
0:24:01
|
depending on what type of neighbor we're sending or receiving the updates from.
|
|
0:24:07
|
Another key point in the vast majority of implementations,
|
|
0:24:11
|
the BGP neighbors are not dynamically discovered.
|
|
0:24:14
|
Whereas with OSPF or EIGRP, we're using multicast packets
|
|
0:24:19
|
in order to find all of the devices running the protocol.
|
|
0:24:22
|
Then, we can establish our unicast relationship with them.
|
|
0:24:28
|
Whereas in the case of BGP,
|
|
0:24:30
|
the BGP peerings are gonna be based simply
|
|
0:24:33
|
on the unicast neighbor statements that we're configuring under the process.
|
|
0:24:39
|
Now, we'll see some of the advanced features of BGP,
|
|
0:24:41
|
there are some corner case scenarios you can configure
|
|
0:24:45
|
where BGP can be set up to dynamically listen for peerings establishments,
|
|
0:24:49
|
but 99% of the time, the neighbors must be statically defined.
|
|
0:24:57
|
Now, another key different from BGP versus IGP,
|
|
0:25:00
|
since we're using TCP as the transport protocol,
|
|
0:25:05
|
it implies that the BGP neighbors do not have to be directly connected on a physical link.
|
|
0:25:11
|
So, this means that my IBGP peers or my EBGP peers could be
|
|
0:25:16
|
a hundred hops away in the network
|
|
0:25:18
|
as long as I have some IGP route
|
|
0:25:21
|
that is going to allow me to establish TCP reachability,
|
|
0:25:24
|
then, the neighbors will be able to establish the peering.
|
|
0:25:29
|
Now, we'll see, there are gonna be some design issues
|
|
0:25:31
|
we have to take into account if the neighbors are not connected
|
|
0:25:35
|
depending on whether this is an EBGP peering, or an IBGP peering.
|
|
0:25:42
|
So, as I mentioned here, BGP is gonna use TCP port 179 for transport,
|
|
0:25:48
|
which means that if the neighbors are not directly connected,
|
|
0:25:50
|
we're gonna have to have some underlying routing protocol
|
|
0:25:53
|
in order to get the basic reachability.
|
|
0:25:57
|
So, technically, you could route the network on BGP alone,
|
|
0:26:01
|
but it would mean that everyone would have to be physically connected to each other.
|
|
0:26:06
|
So, it would have to be a physical full mesh of the network in order to use only BGP.
|
|
0:26:11
|
So, as we know, physical full mesh is not gonna be a feasible design.
|
|
0:26:16
|
So, generally, BGP is gonna just use underlying Interior Gateway Protocol
|
|
0:26:21
|
in order to allow us to do route recursion towards the BGP next hop values.
|
|
0:26:27
|
Now, our first step of the implementation of BGP
|
|
0:26:31
|
is gonna be to start the BGP process
|
|
0:26:33
|
by defining the AS number globally,
|
|
0:26:36
|
and then, specify who are the neighbors that we actually want to peer with.
|
|
0:26:41
|
Now, the neighbor statement is gonna have dual functionality here.
|
|
0:26:45
|
It's gonna tell the router to listen for TCP port 179 traffic
|
|
0:26:49
|
that is coming from that remote address we're defining.
|
|
0:26:53
|
But also to initiate a session to the remote address going to port 179.
|
|
0:27:01
|
Now, depending if both the client and the server tries to establish the session at the exact same time,
|
|
0:27:06
|
a collision can happen in the actual TCP three-way handshake,
|
|
0:27:12
|
in which case, whichever device has the higher router ID
|
|
0:27:16
|
is gonna become the TCP client.
|
|
0:27:20
|
Now, the reason that this could become significant
|
|
0:27:23
|
is that if we're doing any type of application layer filtering
|
|
0:27:27
|
that would potentially block TCP port 179,
|
|
0:27:31
|
or maybe we're going through a network address translation,
|
|
0:27:34
|
then, it could be significant to figure out who is the TCP client, and who is the TCP server.
|
|
0:27:40
|
But since BGP is a standard TCP application,
|
|
0:27:44
|
it's gonna work just like how Telnet does, or how regular HTTP does,
|
|
0:27:50
|
where the client is going to initiate the session going to port 179,
|
|
0:27:55
|
then, the server is going to reply with the session coming from port 179.
|
|
0:28:02
|
So, visually, if we had two routers in the network,
|
|
0:28:06
|
router 1 and router 2 that are trying to establish the BGP peering,
|
|
0:28:12
|
whoever configure the process first
|
|
0:28:15
|
is going to send the first portion of the TCP three-way handshake,
|
|
0:28:20
|
which is the TCP syn packet.
|
|
0:28:24
|
With the source port of some random value,
|
|
0:28:29
|
and the destination port of 179.
|
|
0:28:34
|
Now, if the remote neighbor router 2 is configured to accept the session from router 1,
|
|
0:28:41
|
it should reply with the second portion of the handshake,
|
|
0:28:45
|
which is the TCP acknowledgement saying, "I got your packet."
|
|
0:28:50
|
And a syn saying, "I also want to start the session."
|
|
0:28:54
|
So, the TCP Ack Syn, or the TCP Syn Ack.
|
|
0:28:57
|
When router 2 replies here, it's going to be using the source port of 179,
|
|
0:29:04
|
and the destination port as whatever random value that they are negotiating.
|
|
0:29:10
|
Then, as our final portion of the three-way handshake, router 1 should reply with the TCP acknowledgement,
|
|
0:29:18
|
and then, the session is fully open.
|
|
0:29:22
|
So, from this point on, when we actually go to the BGP capabitliy negotiation
|
|
0:29:27
|
then to BGP update messages and the BGP keepalives,
|
|
0:29:30
|
the keypoint to remember
|
|
0:29:32
|
is that router 1 would always be sending traffic towards port 179.
|
|
0:29:38
|
Where router 2 would be sending traffic from port 179.
|
|
0:29:44
|
So, if we're trying to do any type of access list filtering or any firewall filtering,
|
|
0:29:48
|
we would need to allow traffic going to 179 and coming from 179
|
|
0:29:54
|
in order to match the BGP control plane traffic.
|
|
0:30:00
|
We'll also see what BGP, there's a fundamental difference in the different types of peering.
|
|
0:30:05
|
We have whether they are devices outside of our autonomous system
|
|
0:30:09
|
considered external BGP or EBGP Peers.
|
|
0:30:12
|
Or whether the devices are inside or same autonomous system number,
|
|
0:30:17
|
in which case they would be considered internal BGP or IBGP peers.
|
|
0:30:22
|
We'll see the main differences between the two categories,
|
|
0:30:25
|
is that how the updates are processed?
|
|
0:30:28
|
And how the best path selection algorithm works
|
|
0:30:31
|
is gonna be different depending on if we are advertising updates to EBGP versus IBGP
|
|
0:30:37
|
or whether we are receiving updates from an EBGP versus an IBGP neighbor.
|
|
0:30:48
|
Now, for the EBGP attributes,
|
|
0:30:51
|
the first thing that is noteable about the actual transport in the control plane,
|
|
0:30:56
|
is that the time to live of an EBGP packet defaults to one.
|
|
0:31:01
|
So, this essentially means that by default,
|
|
0:31:04
|
EBGP neighbors must be directly connected on a physical link.
|
|
0:31:08
|
Or some sort of logical Layer 3 direct connection, like maybe a GRE tunnel
|
|
0:31:13
|
or an IP-IP tunnel in order to establish the peering.
|
|
0:31:18
|
So, if we had a case here where between router 1 and router 2,
|
|
0:31:23
|
we had some other device in the middle of the network.
|
|
0:31:28
|
Let's say we have router 1 connecting physically to router 3.
|
|
0:31:34
|
Then to router 2.
|
|
0:31:37
|
If router 1 and router 2 are attempting to establish an EBGP peering,
|
|
0:31:42
|
then when the packet is received by router 3,
|
|
0:31:46
|
since this originally has a time to live of 1,
|
|
0:31:50
|
router 3 would decrement the packet to a time to live of 0.
|
|
0:31:54
|
And then reply back to router 1 with an ICMP unreachable,
|
|
0:32:00
|
that says, "Your TTL or your time has expired."
|
|
0:32:09
|
So, simply based on the normal data plane operation of IP
|
|
0:32:13
|
where the TTL is decremented on a hop-by-hop basis,
|
|
0:32:17
|
it means that the EBGP neighbors normally they would have to be directly attached.
|
|
0:32:21
|
Now, we'll see, there are some different modifications we can do in order to change this behavior.
|
|
0:32:26
|
We could simply modify the TTL with the EBGP multihop command.
|
|
0:32:31
|
So, if we say Neighbor 1234 EBGP multihop,
|
|
0:32:35
|
it means that as I send packets out to that peer,
|
|
0:32:38
|
I'm gonna use a time to live value of 255, which is the maximum.
|
|
0:32:43
|
We could also do some sort of administrative scoping with the TTL.
|
|
0:32:47
|
If I want to assume that my remote neighbor is gonna be less than 5 hops away,
|
|
0:32:51
|
I could say Use EBGP Multihop with a TTL of 5.
|
|
0:32:57
|
Now, another key feature that we'll see as a very common in implementations today
|
|
0:33:03
|
is the TTL security feature that is designed to prevent against remote TCP reset attacks
|
|
0:33:10
|
or remote TCP MD5 authentication attacks
|
|
0:33:14
|
that are essentially denial of service attacks against either the router's CPU
|
|
0:33:18
|
or against the control plane itself.
|
|
0:33:22
|
So, these two commands, the EBGP Multihop or the TTL Security,
|
|
0:33:25
|
those are mutually exclusive.
|
|
0:33:27
|
you would use one or the other but not both of them at the same time.
|
|
0:33:32
|
Now, for some reason, the devices are directly connected.
|
|
0:33:36
|
But they're not using an address that is on that connected link.
|
|
0:33:41
|
Then there's also an option to disable the connected check
|
|
0:33:45
|
without actually incrementing the TTL value.
|
|
0:33:49
|
And the typical design for this would be if the two routers are directly connected,
|
|
0:33:54
|
So, if we have router 1 physically connected to router 2,
|
|
0:34:00
|
but then we want to do the peering based on their loopback addresses,
|
|
0:34:04
|
because maybe we have two interfaces between them.
|
|
0:34:06
|
We have Fast Ethernet 0/0 adn Fast Ethernet /1.
|
|
0:34:11
|
And we wanna make sure that if one of these physical links goes down,
|
|
0:34:15
|
that the control plane session can maintain over the available link.
|
|
0:34:21
|
So, in this type of design, when router 1 sends the BGP message,
|
|
0:34:26
|
regardless of what interface it goes out,
|
|
0:34:28
|
if the TTL is 1, when router 2 receives this,
|
|
0:34:33
|
it's not gonna have to decrement the TTL because the packet is locally destined.
|
|
0:34:38
|
However, we'll see that the default behavior
|
|
0:34:41
|
is that when the router goes to establish an EBGP peering,
|
|
0:34:45
|
if it looks in the routing table for the neighbor's destination address,
|
|
0:34:49
|
and it doesn't find a directly connected route,
|
|
0:34:53
|
the neighbor does not send the open message.
|
|
0:34:56
|
So, it doesn't try to initiate the TCP 3-way hand shake.
|
|
0:35:01
|
If we say Neighbor Disable Connected Check, then it's gonna skip over that.
|
|
0:35:06
|
Send the open message.
|
|
0:35:07
|
If the packet is actually lost due to the TTL, then it's up to the transport network's fault.
|
|
0:35:15
|
So, we'll see there are cases where you may wanna do both of these at the same time.
|
|
0:35:19
|
The EBGP multihop and the neighbor disable check.
|
|
0:35:21
|
It depends on whether we are trying to initiate the BGP peering
|
|
0:35:25
|
or whether we are trying to just accept the BGP peering.
|
|
0:35:31
|
Our next keypoint about EBGP peerings
|
|
0:35:33
|
is how the loop prevention is used with the AS path information.
|
|
0:35:39
|
So, everytime I send an update to one of my BGP peers,
|
|
0:35:42
|
I'm gonna take my local autonomous system and add it to the autonomous system path attribute
|
|
0:35:48
|
that is inside the actual update.
|
|
0:35:51
|
Where the AS path is just gonna track
|
|
0:35:53
|
what are the different autonomous systems that this route went through
|
|
0:35:56
|
from the originator to whatever my local autonomous system is.
|
|
0:36:02
|
So, if we look at the output of that local BGP table we saw,
|
|
0:36:05
|
For this particular prefix,
|
|
0:36:08
|
that the routers receiving here, the 1.9.0.0/16,
|
|
0:36:14
|
the AS path information on the right most portion of the output
|
|
0:36:18
|
tells us that this route was originated by AS 4788.
|
|
0:36:23
|
Then it was advertised to AS 7018.
|
|
0:36:27
|
Then whatever the local autonomous system on this router is,
|
|
0:36:29
|
7018 is the peer that they are receiving it from.
|
|
0:36:34
|
Where in this case 7018 is AT&T's autonomous system number.
|
|
0:36:39
|
So, the way that we read the AS path information,
|
|
0:36:43
|
the number that is on the left most portion,
|
|
0:36:45
|
that is the AS that we are learning the update from.
|
|
0:36:48
|
Where the number on the right most portion,
|
|
0:36:51
|
that is the AS that the prefix was originated in.
|
|
0:36:55
|
So, whoever has AS number 18313,
|
|
0:36:59
|
is actually the owner of the prefix 1.11.0.0/21.
|
|
0:37:06
|
Now, the keypoint being here,
|
|
0:37:08
|
is that whenever we send an update outbound,
|
|
0:37:10
|
we're gonna take our own local autonomous system number
|
|
0:37:13
|
and put it as the first number in the AS path.
|
|
0:37:16
|
So, we're adding it to the front or pre-pending it.
|
|
0:37:19
|
If for some reason I received that update back inbound,
|
|
0:37:23
|
if I see my local autonomous system number in the path,
|
|
0:37:27
|
then I'm automatically gonna filter that update out.
|
|
0:37:32
|
So, the basic loop prevention logic is that for updates that I am sending outbound,
|
|
0:37:37
|
there's no reason that I should eventually receive those back inbound.
|
|
0:37:42
|
now,we'll see, we can modify this if we want to
|
|
0:37:44
|
with the neighbor allow AS in command.
|
|
0:37:47
|
In cases that we have the same autonomous system number
|
|
0:37:50
|
that are separated by a different autonomous system number in the middle.
|
|
0:37:55
|
But for the vast majority cases, you wouldn't change this.
|
|
0:37:58
|
This is gonna be the normal EBGP loop prevention logic that we would want to have.
|
|
0:38:06
|
Another keypoint about EBGP,
|
|
0:38:08
|
is how it does its next hop processing different than IBGP does.
|
|
0:38:14
|
So, when we are sending updates outbound,
|
|
0:38:17
|
whatever the local addresses that we're using for that particular peering,
|
|
0:38:22
|
is gonna be the IP address value that goes into the next hop attribute of the route.
|
|
0:38:28
|
So, for example if we were to have router 1 and router 2,
|
|
0:38:33
|
peering via their loopback interfaces, and these are EBGP peers,
|
|
0:38:38
|
and let's assume that router 1's loopback is 1.1.1.1.
|
|
0:38:42
|
Router 2's loopback is 2.2.2.2.
|
|
0:38:46
|
And router 1 is advertising some prefix 10.0.0.0/24.
|
|
0:38:52
|
When this update is actually advertised to router 2 over the EBGP session,
|
|
0:38:58
|
router 2 is gonna say that the prefix 10.0.0.0/24 is reachable via the next hop 1.1.1.1.
|
|
0:39:08
|
This would then imply that router 2 needs an additional step in the route recurssion
|
|
0:39:13
|
to figure out what is the local connected interface
|
|
0:39:16
|
that I would use in order to actually reach that destination 1.1.1.1.
|
|
0:39:23
|
So, the normal routing look up logic that we talked about before in IGP,
|
|
0:39:29
|
it is gonna be very important to understand that
|
|
0:39:31
|
before we see how the operation of BGP works.
|
|
0:39:35
|
Because in cases where we cannot do full route recursion towards the next hop value,
|
|
0:39:40
|
it means that those BGP routes are going to be invalid.
|
|
0:39:43
|
We won't be able to install them in the routing table.
|
|
0:39:45
|
And we won't be able to advertise them.
|
|
0:39:52
|
Now, technically, we could modify the next hop value,
|
|
0:39:56
|
just like any other attribute that we can in the update.
|
|
0:39:58
|
Whether it'd be the local preference or the AS path or the multi-exit discriminator.
|
|
0:40:04
|
But for EBGP sessions, typically, we would not do this in a normal design.
|
|
0:40:09
|
But technically, you can.
|
|
0:40:11
|
This type of implementation is called a third party next hop.
|
|
0:40:14
|
Where I am sending you an EBGP update.
|
|
0:40:18
|
But then telling you to use some other device in the actual data plane in order to get there.
|
|
0:40:25
|
So, we technically could have a case where we have router 1 peering with router 2.
|
|
0:40:35
|
Router 2 then has a connection to router 3.
|
|
0:40:39
|
Then maybe 1 and 3 are connected via some LAN interface.
|
|
0:40:44
|
Where router 2 sends an update.
|
|
0:40:46
|
Or router 1 sends an update to router 2. Let's say this is 10.0.0.0/24.
|
|
0:40:52
|
And instead of using the normal next hop value,
|
|
0:40:56
|
which would be whatever the update source is from router 1 to router 2,
|
|
0:41:00
|
we could tell router 2 to use router 3.
|
|
0:41:07
|
So, the control plane for BGP
|
|
0:41:12
|
is gonna be on the session between router 1 and router 2.
|
|
0:41:15
|
But then the actual data plane which is the traffic forwarding
|
|
0:41:19
|
would be through some other device.
|
|
0:41:21
|
So, if this is the prefix here, 10.0.0.0/24, and router 3 has the address 3.3.3.3,
|
|
0:41:30
|
it means that the routing update would be coming that direction.
|
|
0:41:34
|
But the actual traffic flow would go in a separate direction.
|
|
0:41:40
|
So, we'll see, one of the very flexible features about BGP
|
|
0:41:43
|
is that the controal plane is not directly tied to the data plane.
|
|
0:41:47
|
Where as in IGP, the control update maps on a one-to-one basis as to what the data plane forwarding is.
|
|
0:41:57
|
Now, what I mean by that, if we were to have 2 EIGRP routers,
|
|
0:42:01
|
that are directly connected, router 1 and router 2,
|
|
0:42:06
|
when router 1 sends an EIGRP update to router 2,
|
|
0:42:14
|
router 1 is always gonna say, "Use the address of this link in order to reach the destination."
|
|
0:42:20
|
So, the outbound path of the update is the mere image of the inbound path of the traffic.
|
|
0:42:27
|
So, there's no way for router 1 to say, "I actually want you to go to some other device
|
|
0:42:32
|
and the network in order to actually reach that destination."
|
|
0:42:37
|
But inthe case of BGP, the next hop value
|
|
0:42:40
|
is just like any other attribute in the update.
|
|
0:42:43
|
That we do technically have the flexibility to change to be whatever value that we choose.
|
|
0:42:51
|
Now, our next type of peering with IBGP,
|
|
0:42:54
|
one of the key things to note that is the first difference between EBGP and IBGP
|
|
0:42:59
|
is that there is no time to live restriction on the internal BGP packets.
|
|
0:43:04
|
So, IBGP uses a TTL of 255,
|
|
0:43:07
|
which means that the neighbors do not have to be directly connected.
|
|
0:43:11
|
So, as long as there is IGP reachablity between the two devices in the internal network.
|
|
0:43:17
|
It's going to allow us to establish the BGP peering and then ultimately advertise the prefixes.
|
|
0:43:24
|
Now, we'll also see that based on the next hop processing rule of IBGP,
|
|
0:43:29
|
the contol message again does not necessarily have to follow the actual data plane forwarding.
|
|
0:43:36
|
So, this means that I could be a source of a BGP update that is going to you.
|
|
0:43:41
|
But it doesn't really necessarily mean that I'm gonna be receiving your traffic.
|
|
0:43:45
|
So, there's a disconnect between the control plane and the data plane.
|
|
0:43:49
|
That's gonna give us more flexibility in our actual traffic engineering
|
|
0:43:53
|
to figure out how the traffic is getting from point A to point B.
|
|
0:44:01
|
Now, the loop prevention for IBGP uses a very simple...
|
|
0:44:06
|
a very simple concept.
|
|
0:44:08
|
It simply says that if you learn a route from an IBGP neighbor,
|
|
0:44:11
|
don't advertise it to other IBGP neighbors.
|
|
0:44:15
|
So, if I learn a route fromyou and you're my IBGP peer,
|
|
0:44:18
|
I'm gonna prevent a loop of that route just by not advertising to my other internal peers.
|
|
0:44:25
|
This implies that by default, in an IBGP design,
|
|
0:44:28
|
all of the internal routers have to have direct peering with each other.
|
|
0:44:33
|
Or they have to have a full mesh of IBGP peers.
|
|
0:44:38
|
Now, a full mesh of peers is gonn agive us the most reachability information about the network.
|
|
0:44:44
|
And it's gonna allow us to make the most intelligent decision
|
|
0:44:47
|
as to how traffic should exit out of our autonomous system.
|
|
0:44:52
|
The problem though is that there's a give and take between the amount of control plane information
|
|
0:44:57
|
and then the amount of resources that's gonna take to actually process that and maintain it.
|
|
0:45:02
|
So, doing a full mesh of BGP is the most efficient in terms of selecting the correct path information.
|
|
0:45:10
|
But it means there's gonna be a lot of extra overhead for the amount of updates,
|
|
0:45:13
|
the amount memory that we need and just the amount of administration
|
|
0:45:17
|
that would be required to configure the peering statements for every single device in the network.
|
|
0:45:24
|
So, in a lot of design, if the BGP is more than maybe 10 routers or so,
|
|
0:45:30
|
there's gonna be some alternate design used either with route reflection or confederation
|
|
0:45:35
|
to cut down on the amount of peerings that we use.
|
|
0:45:39
|
Now, we'll also see in most designs, it would make sense to take your route reflection or your confederation
|
|
0:45:45
|
and to make it follow the physical path of the network.
|
|
0:45:48
|
So, if there's some sort of physical aggregation point
|
|
0:45:51
|
that to get from point A to point B, I have to go through this aggregated router.
|
|
0:45:56
|
Then it would make sense for them to be the route reflection
|
|
0:45:59
|
or one of the termination points of the confederation.
|
|
0:46:04
|
So, as we get to the actual implementaion of that, we'll see some of the different design issues
|
|
0:46:09
|
of where we would want to place the route reflectors
|
|
0:46:11
|
and then ultimately what are the configuration implications of doing those type of designs.
|
|
0:46:20
|
Now, our next keypoint got IBGP,
|
|
0:46:23
|
as I mentioned that the next hop processing is different between EBGP updates and IBGP updates.
|
|
0:46:31
|
Where with IBGP updates, when we send a routing update to an IBGP neighbor,
|
|
0:46:37
|
regardless of what type of neighbor they are, whether they are a regular IBGP peer,
|
|
0:46:41
|
a client peer if I'm a route reflector, a non-client peer if I'm a route reflector,
|
|
0:46:46
|
or a confederation EBGP peer.
|
|
0:46:50
|
So, someone that's part of my confederation but they're on a different sub autonomous system,
|
|
0:46:55
|
I am not going to change the next hop attribute value.
|
|
0:46:59
|
So, what this essentially means is that the original entry point for the route,
|
|
0:47:06
|
is going to be maintained throughout all of the updates in the IBGP network.
|
|
0:47:13
|
So, if we were to have a design
|
|
0:47:15
|
where there is some exit point A out of the network,
|
|
0:47:20
|
and we have router 1 peering with router 2.
|
|
0:47:27
|
Then we have some other...
|
|
0:47:30
|
downstream devices. Router 3, router 4.
|
|
0:47:32
|
Okay, maybe we have a very diverse physical connectivity in the netowrk.
|
|
0:47:37
|
If router 2 were a route reflector,
|
|
0:47:42
|
and we looked at the path of the update advertisement
|
|
0:47:45
|
where router 1 learns this route from an EBGP neighbor.
|
|
0:47:49
|
Sends it to our IBGP peer, who is the route reflector.
|
|
0:47:54
|
The route reflector sends it down to its clients,
|
|
0:47:58
|
Through the IBGP session.
|
|
0:48:02
|
The next hop attribute of the original route,
|
|
0:48:05
|
which is exit point A is not going to be modified in any of these updates.
|
|
0:48:13
|
So, this means that when we look at the difference between the control plane advertisement
|
|
0:48:18
|
and the actual data plane forwarding,
|
|
0:48:20
|
router 3 would not have to physically forward the traffic to the route reflector in order to get to A.
|
|
0:48:27
|
If router 3 had a closer exit via an IGP route to A through router 1,
|
|
0:48:33
|
the outbound traffic could skip over the route reflector
|
|
0:48:37
|
because we're recursing to the next hop value that is not being changed.
|
|
0:48:44
|
So, we'll see the vast majority of the time not changing the next hop value
|
|
0:48:47
|
is actually a design advantage for BGP.
|
|
0:48:51
|
Where it's gonna give us the opportunity to choose the shortest path
|
|
0:48:55
|
to the exit point of the network or towards the edge router of the network.
|
|
0:48:59
|
And then not have to use either the centralized route reflector or some of the confederation peers
|
|
0:49:06
|
in order to actually reach the destination.
|
|
0:49:13
|
So, the keypoint to remember here
|
|
0:49:16
|
is that it's not gonna be modified no matter what type of IBGP peer it is.
|
|
0:49:20
|
A regular one, any type of route reflection or confederations.
|
|
0:49:24
|
Next hop value is always gonna be the value that came from your EBGP neighbor to begin with.
|
|
0:49:33
|
Now, we can manually modify this if we want to
|
|
0:49:36
|
with the neighbor next hop self command.
|
|
0:49:39
|
This would take routes that we're learning from EBGP peers.
|
|
0:49:43
|
Then as we're advetising them in to IBGP peers,
|
|
0:49:46
|
we would be setting the next hop value to whatever our local peering address is.
|
|
0:49:51
|
So, essentially, whatever is the update source of that particular neighbor.
|
|
0:49:56
|
We also have the flexibility to use a route map
|
|
0:49:59
|
with the set IP next hop keyword.
|
|
0:50:02
|
Which allows us to do that third party next hop routing,
|
|
0:50:05
|
where we could say that the exit point is wherever that we want in the network.
|
|
0:50:11
|
But again, the keypoint here is we'll see with BGP,
|
|
0:50:14
|
it's very flexible because we have that disconnect in the control plane versus the data plane.
|
|
0:50:19
|
So, essentially, whatever type of policy that we want to implement
|
|
0:50:22
|
for our outbound traffic versus our inbound traffic
|
|
0:50:25
|
BGP is gonna give us the flexibility to do that.
|
