[MUSIC PLAYING]
Before we can really jump in and talk
about manipulating BGP's attributes in order
to influence our path selection, we
have to talk about how that information is going to be
propagated to the neighbors.
BGP does not consider the changing of attributes
to be an actual change to the prefix.
If the prefix itself was changing,
such as maybe the subnet mask, maybe somebody
summarized it so maybe a route needs to be withdrawn,
or a new route needs to be advertised, or something
like the next hop changes, those are major routing events
and prefix changes.
BGP will, of course, send those to its neighbors.
If it didn't, it wouldn't really be
very much of a dynamic routing protocol.
But the attributes, the things that we're
trying to use to influence BGP's path selection,
don't automatically trigger an update to the neighbors.
This is something that we're going
to have to do manually when we make changes.
Now there are a few ways to do that.
And that's what we're going to be discussing in this video.
We could, of course, do a hard reset.
And that's going to be disruptive.
That's going to take the neighborship down, bring
the neighborship back up, and then readvertise
all the prefixes which, of course, would
include the new attributes.
But that's going to be very disruptive to network traffic.
And in most environments, we're not going to want to do that.
So we have two other choices which is
the main topic of this video.
We're going to be talking about soft reconfiguration
and something called route refresh.
Now route refresh is generally considered newer
and that's generally what we use.
However, soft reconfiguration does have one advantage
that you might want to consider to help us maybe a little bit
with some troubleshooting.
So let's jump in and get started.
And we'll take a look at the attributes
of each different method.
So the first option we'll discuss
is soft reconfiguration.
And as we said during the introduction,
this is sort of considered the older way
of accomplishing this.
So let's jump in and talk about its attributes.
First, it stores a copy of the routes that
were received from a neighbor before running those routes
through the inbound policies.
So the idea here is we can take this stored copy
and run it back through our inbound filters again
if those inbound filters change.
The big advantage to this, of course,
is we don't have to do a hard reset on the neighborship.
We simply replay the locally stored copy.
Now this feature is not enabled by default
so it does have to be manually enabled in order to use it.
And the reason for this we'll see you
in the next couple of points here.
Something else to note that on iOS XR,
this actually will not work by default
if the neighbor supports the newer route refresh.
Even if you enable this feature, it
will still do a route refresh if the neighbor supports it
since that is generally considered
to be the newer method.
And we'll see this when we get to our demonstration.
Now I think that the main reason we still
want to discuss soft reconfiguration
is because of this point right here.
This can be very useful, specifically
for troubleshooting.
And what we mean by this--
troubleshooting your inbound filters.
If your inbound filters are not correct
and you are filtering out things you don't want to,
or maybe you're not filtering out the things you do want to,
in any case, it can be incredibly
useful to see the before copy of the routes
that you're getting from your neighbor
compared to what you're putting into your routing table or BGP
table.
So the way this is useful is allowing
you to see that before and after snapshot of the prefixes being
learned from a neighbor and therefore get
a really good idea of what your inbound filters are doing.
Now given all this information about how this works,
hopefully, it's no big surprise that this
is going to take additional RAM on that router.
The before and after BGP tables do have to be stored somewhere.
Now the after table, of course, we
will always have so that's not additional.
But storing that before copy of the BGP table from the neighbor
is definitely going to take more RAM.
On today's equipment, that probably
doesn't matter a whole lot but we do still
need to take it into consideration when
we're going to consider enabling this feature.
Now the second option here is route refresh.
And as I mentioned, this is generally
considered to be the newer option.
This entails actually requesting the full BGP table
to be resent.
That's the key here.
We're not storing the unaltered copy anymore.
If we change our inbound filters,
we simply ask our neighbor to send all the updates again
and then we run them through our new filters.
So rather than us storing a copy,
this gives us a mechanism to simply request
the neighbor to send us another copy on its own.
The reason for doing this is to take those new updates
and pass them through the changes
to our new inbound policies.
But we don't store a local copy.
Now this capability is going to have to be negotiated
when the neighborship comes up.
I cannot send you a route refresh message if you
don't understand route refresh messages.
So I have to know that you know what they are.
This feature was not in BGP from the beginning.
So therefore, there is a possibility
that a BGP router on the other end
would not understand this feature.
Now this is another one of those features
that every vendor out there that I'm
aware of supports route refresh but it doesn't mean they
have to.
So we do have to negotiate this so that both routers are
on the same page and they know whether their neighbor supports
this before we just go asking for a route refresh
and the other router has no idea what we're talking about.
So those route refresh messages that we just mentioned come
in a few different flavors.
First, we have the refresh request.
Then we have a start of rib message telling us
that it's about to send the rib to us.
Then we have an adjacency rib out and an end of rib message.
Now we don't really have to be familiar with these
in great detail.
However I would be aware of the different message
types used by route refresh.
And here's arguably the best feature of this whole thing
is most modern code, most new versions of iOS, both XR
and XE, have this feature enabled by default.
And in fact, most of them will prefer this
even if you enable soft reconfiguration.
We might have to force soft reconfiguration
to happen over route refresh, particularly on iOS XR,
but we'll see that in our demonstration.
And one final point here that since this is not taking up
extra RAM, what we're doing instead
is we're going to be asking our neighbor to resend this.
That's exactly what we mentioned up here.
The whole concept of resending is, of course,
going to take bandwidth on the link
and therefore slightly more time.
Now, I wouldn't consider the extra time
to really be an issue on most of today's networks
with our available bandwidth.
However, we can't really argue the fact
that getting the neighbor to resend it
is still going to take even marginally more time than just
replaying a local copy out of our own local RAM.
In our next video, we're going to be
taking a look at the command line and Wireshark
to get a better idea on how these two features work.
So let's jump in and take a look at the topology
so we have an idea what we'll be looking at when we start
jumping into the command line.
So for this skill, we will be using BGP topology I.
And our topology doesn't really matter
for this particular demonstration.
Of course, it will be much more important in the other videos.
But in this one just looking at the route refresh,
we're just going to focus on router 1 and router 7.
This way we can see how both iOS XR and iOS XE operate.
So in this video, we took a look at two
features we have available in BGP
that allow us to send prefixes with modified
attributes to our neighbors without actually
having to do a hard reset.
So we started off by looking at the older method,
doing soft reconfiguration inbound, where
we keep a local copy of the unmodified BGP table
before we run it through our inbound filters.
Then, we took a look at the more modern way
of doing this, route refresh, where we actually
send a message to our neighbor router asking them to resend
the updates to us so that we can run them
through our new modified filters.
I hope this has been informative for you.
And I'd like to thank you for viewing.