[AUDIO LOGO]
In this video, we're going to be taking a look at AS path
prepending.
The idea behind AS path pretending
is to influence BGP path selection based
on the shortest AS path rule.
The way we do that is by adding AS numbers to the path
that we do not want our neighbors to use.
And since we're doing this to influence our neighbors,
that essentially means that we're doing
this to affect inbound traffic.
Now, like other things we've discussed in this course,
of course, using things like BGP communities and such,
we could use them for other things.
And technically, we could use this
for outbound path selection.
But again, this would not be done very commonly.
So let's jump in and take a look at some of the details
of our AS path prepending.
So AS path prepending is following
BGP rule number 4 where we're, of course,
going to prefer the path with the shortest AS path.
So again, this is about the number of AS's.
It's not about the actual length as far as number of digits.
Now, one quick note.
This can actually be disabled.
I would generally not recommend doing it.
But this step can be skipped if you configure this command--
"bgp bestpath as-path ignore."
Again, this is not something we generally want to do.
In fact, a lot, I would say, the majority of BGP path selections
happen based on this rule.
However, there could be reasons you want to change that.
So it's good that we can turn it off in certain circumstances,
but it's not, again, a very common thing to do.
And since we are concerned about the number of AS's, it's
also important to note that if we have an AS_SET,
that always counts as one.
It doesn't matter how many AS's are in that set.
The set itself counts as one AS for AS path prepending.
Another caveat here is that the CONFED_SEQUENCE
and the CONFED_SET are also not included in the actual length.
This is because it's, of course, trying to only count
external AS numbers.
Of course, the AS path itself is a well-known and mandatory
attribute.
So well-known, of course, meaning that all BGP speakers
will understand the AS path.
Mandatory, meaning that it must be in every update.
Now, that, of course, doesn't mean that we
have to actually do prepending.
It just means that the AS path has to be present.
Now, this is relatively high on the BGP path selection list.
It's rule number 4, which puts it pretty high to the top.
The reason that it's important to understand that this
is high on the BGP path selection
is when we send an AS path prepend to a neighboring AS,
we need to be fairly confident that they will, in fact, be
influenced by that AS path.
Now, of course, if the policy in that neighboring AS
is implementing something like local preference,
or wait, to override what we're trying to do with AS path
prepending, well, those attributes would, of course,
still win because they are higher on the list.
But generally speaking, neighboring AS's would not
be purposefully trying to override what we're
doing with AS path prepending.
Just be aware, of course, that they can,
just because wait and local preference
are higher on the list.
Again, the rule here is to prefer the shorter AS path.
And again, it's the length, meaning how many AS's not
based on the actual AS numbers, which would more
be about the number of digits.
And as we mentioned during the introduction,
this is normally used to influence the inbound traffic
in a multihomed AS environment.
Technically, we could use AS path prepending to control
our outbound traffic.
But again, given that we already have wait and local preference,
there's not really any reason to do that.
So again, it's not commonly done.
So again, the reason this is so important
is because just generally trying to get
another AS to return your traffic on a certain path
directly.
Basically, what we mean by that is
like calling up another service provider,
or calling a customer, and saying,
"Listen, could you modify your policy
to send traffic a certain way?"
That's what we mean by directly.
They're not going to generally change
their policy based on what you would like to happen.
And particularly, if you're looking
at this from the customer side, the service provider
is certainly not going to change their policy for a customer.
Now notice we put here-- and we've mentioned this a few
times now--
communities, of course, can be an exception.
As a service provider, we can, of course,
write policies, route maps, to accept certain communities,
and then select certain paths for the customer.
So the overall idea, again, is we're
going to be manually manipulating the AS path
length.
We're going to take the originating AS's number.
And we're going to add it a number of times
to the end of our normal AS path.
The reason we usually use the originating AS's number is,
that way, we don't interfere with BGP loop prevention.
We don't want this traffic to arrive
at an AS that actually is the AS number that we prepended.
So since our own routes should never come back to us,
it wouldn't be a problem to use our own AS number to prepend.
That's why it's normally done that way.
Understand, though.
There's nothing technical to stop you from prepending,
honestly, any numbers you want to for whatever reason.
But normally, again, it's going to be the originating AS's
number.
That's how this is commonly used.
This is, of course, in addition to the normal AS
path prepending that we normally do in eBGP updates.
That means that if we prepend three times,
like I indicated up here, that we would actually
be adding our AS number four times to this update,
the three that we prepended, as well
as the one that would, of course,
normally be put on that update.
Now, there is one thing we need to be concerned with when
it comes to AS path prepending.
And that is, it may not pass the neighboring AS's
inbound filters.
It's actually quite common, for example, for a service provider
to filter the updates coming from a neighbor
to only allow updates with that neighbor's AS on it
as the only AS.
So, for example, if one of my customers was AS 65,001,
I would not accept any updates from that customer that
weren't originated from 65001.
Now, what I can do is write my filter
to allow multiple instances of that same number.
And that's quite commonly done as well.
But if it's not written that way,
then prepending would be a problem.
If the person that I'm trying to send these updates to
does not accept multiple instances of the AS number,
then prepending is not going to be our option.
So this means we probably want to verify
with neighboring AS's how they're
configuring their filters.
So just to summarize the whole idea here
of AS path prepending, the basic idea
is we're going to taint the path that we want to be the backup.
So if we don't want a path to be used,
that's the one that we would do our AS path prepending on.
In this video, we talked about using
AS path pretending to affect the return path into our AS.
So the basic idea being we're going
to add multiple copies of the originating AS number
to the path that we don't want to use, therefore
causing our neighboring AS's to return
traffic to us across the alternate path, rather
than the one that we added all of the AS numbers to.
In the next video, we're going to take a look at an example
of how this would work with multiple AS's.
I hope this has been informative for you.
And I'd like to thank you for viewing.