[AUDIO LOGO]
In this video, let's jump into the command line on both iOS XR
and iOS XE, and we'll get an idea
how route-refresh and software configuration work
on the two different platforms.
We'll also take a look at Wireshark,
so we can see the messages actually being
sent between the two routers on the wire.
So let's jump in and get started.
We'll start on the command line of router 1 looking at iOS XR.
So since router 1 is running iOS XR,
this will do route-refresh automatically by default.
So let's actually begin by going into configuration mode
into BGP, and let's do our neighborship towards router 7.
So that's 50.0.167.7.
We'll go into our address family for IPv4
and let's configure soft reconfiguration,
and you can see here, it only supports inbound.
We haven't really mentioned this before because there's not
much to it.
Doing an outbound reconfiguration
is actually quite simple.
There's no special feature or anything like that.
We simply resend our local BGP table to the neighbor
through any new outbound filters.
So again, we haven't really talked about it
because there's honestly nothing to talk about.
The other router may not be expecting an update from us,
but it'll process it if it comes in.
So there's no notification or any extra storing of tables
or anything else that needs to happen.
For outbound, we just do it.
So that's why the only option here is inbound,
and why we haven't really discussed it.
So let's go ahead and do inbound.
We'll commit those changes, and we'll exit configuration.
Now the first thing we want to note
is if we do a show BGP neighbor for that 50.0.167.7
and we do a received routes, there's not
going to be anything shown, and it actually
tells us right here that this command is only available when
inbound soft reconfiguration is active.
And it also tells us that it's not
going to be active if the neighbor supports
route-refresh.
Now the cool thing is it does tell us here how to fix it,
but we're not going to fix it just yet.
We're going to verify first that it
is in fact using route-refresh and ignoring
the soft reconfiguration that we just configured.
Obviously, we can see that it is, but let's take a look at it
both in debug and in Wireshark.
So first let's turn on our debugs.
So we'll start with a debug BGP update for the address family
IPv4 unicast, and let's jump over
and do a Wireshark capture.
So here we've started a capture on gigabit 3 of router 1,
and we are filtering it to be BGP but not
if the BGP length is 19.
That should specifically keep out BGP
keep alives just so we can see the updates themselves.
So now let's go do a clear on our BGP session.
So we'll say clear BGP IPv4 towards that neighbor,
and we'll do a soft inbound.
So what we see here is it's actually
sending that refresh request over to router 7,
and then we see that we're actually getting our updates
as we requested them.
So as we can see this did not do soft reconfiguration,
it's clearly a route refresh.
We see the request go out, and we see the updates coming in
on our debug.
Let's go see what Wireshark showed us.
So if we take a look here at Wireshark,
we can clearly see that the first message sent here
was from router 1 to router 7, and it is in fact
a route-refresh message.
If we expand the route refresh message,
we can actually see here that it was specifically
for address family IPv4.
And then if we look back up at the top,
we can see that our second message coming in
are the update messages coming from router 7
to router 1 actually doing the route-refresh.
So this was definitely a route-refresh scenario.
So let's go back over to router 1
and take a look at how we get iOS XR to actually do
the soft reconfiguration inbound if the neighbor supports
route-refresh.
So before we go ahead and fix it there's
one more command we can look at here,
the show BGP neighbor detail.
And if we scroll down a bit, we can see right here
under neighbor capabilities that route-refresh
is both advertised and received, meaning both sides support
route-refresh.
So router 1 knows this.
This is why router 1 is doing the route refresh rather than
the soft reconfiguration inbound.
So if we want it to actually do that,
we're going to have to force it.
To do that, we'll go back into configuration mode,
back into the router, back into the neighbor,
back into the address family, and
after the soft reconfiguration inbound,
we're going to have to turn on always.
We'll commit those changes.
Notice that since we still have our debug on, as soon as we
said commit, look what it did.
If we scroll up just a little bit here,
we can see right here that it sent a route-refresh request.
So there's a little bit of irony.
It's doing a route-refresh to populate the local table to do
soft reconfiguration inbound.
So there's nothing wrong with this,
it's just a little interesting that it uses the newer
method of doing a refresh, which is the route-refresh request
to populate the table that we're going
to be using for our soft reconfiguration inbound.
So let's see if that table is actually populated now.
So now let's look at our received routes
again, and notice that now we're getting a prefix from router 7.
So this is working properly.
We now have this local copy.
Also if we were to do a show IP BGP for the prefix 108.8.8.0,
notice here on the entry from router 7,
it's listing it as both received and used.
This means that it was received through soft reconfiguration.
It's being stored locally, and it also
happens to be, in this case, the path that we're using.
Also if we look at the details of that neighborship now,
notice that under address family IPv4,
next to the inbound software configuration allowed,
it actually says to override route-refresh.
So now that this is supposedly working properly,
let's verify it.
So let's go ahead and do a soft clear to that neighbor again.
So the main thing we want to see here
is that it did not send a route-refresh message.
Now it's showing the replay of the local table that's
what these debugs are, but there's
no route-refresh message being sent.
In fact, we can see right here that it's
marking the neighbor for soft reconfiguration.
We could also see this in Wireshark.
Notice that we only have two route-refresh messages here.
The first one is the one we looked at initially.
The second one is from when we enabled
the soft reconfiguration inbound.
We saw that it did a route refresh
to get that information.
But notice this third time that we did the clear,
there's no route-refresh message for the third time
we clear the neighborship.
So we can see clearly this is doing software reconfiguration
now.
So let's go back to router 1.
First let's turn off all of our debugging,
and now let's look at this same feature on iOS XE.
So let's jump over to router 7 next.
So first on router 7, let's look at its default behavior.
So let's start with a debug IP BGP update.
Then we'll do an inbound clear to our router neighbor.
So although this one doesn't actually say in the debug
that it sent a route-refresh request,
we can see that as soon as we hit Enter, all of a sudden
we received all these updates coming from router 1.
So that's a pretty good indicator
that it was a route-refresh.
We can also, of course, see this in Wireshark.
As we can see here in Wireshark, we now
have a third route-refresh message in our output.
And notice that this one is coming from the source of .7
going to the destination of .1 So this is 7 asking 1
for the route-refresh.
So this is showing that default behavior.
Something else of interest to note on iOS XE.
If we come back over here to router 7
and instead we do a soft in and hit Enter,
we'll notice that it actually does the exact same thing.
There's no difference between soft in and in on iOS XE.
This is still doing a route-refresh.
If we look at Wireshark, there's a second request
now from router 7 to router 1, so this is clearly
sending out refresh messages.
The point is that both commands do the same thing on iOS XE.
Now let's turn on soft configuration
and see what changes.
So first we'll go into configuration mode.
Router BGP 65001.
For the neighbor, 50.0.167.1.
We will do soft configuration.
Just like iOS XR, inbound is, of course, the only option.
We'll end our configuration.
And as we can see, just like iOS XR,
this already did another route-refresh
to populate the soft reconfiguration inbound table.
So this is doing the exact same thing.
Now if we do our clear in again, notice
how it's just doing a soft reconfiguration inbound.
It did not get all those updates again,
and it completed in 2 milliseconds.
The other update really didn't tell us how long it took,
so we don't really have a comparison,
but it was pretty quick.
Also note that if we again do the soft in,
this is going to do the exact same thing.
So these two commands in and soft in on iOS XE
do exactly the same thing.
The only real difference is whether soft reconfiguration
inbound is enabled or not.
Just as a quick note in case you're wondering why there's
two different commands, on older versions of the code going back
quite a bit, in was to do route-refresh,
soft in was to do soft reconfiguration inbound.
And if you tried to do soft in without enabling the feature,
the router would yell at you and say, no, you can't do that.
You haven't enabled soft reconfiguration inbound yet.
Now it just looks and sees, oh, well, route-refresh is enabled.
That's good enough.
So I see that you type soft in, but we'll just
do a route-refresh.
So both commands on current code do the same thing just
based on whether soft reconfiguration inbound is
enabled, and of course, assuming route-refresh
was negotiated with the neighbor during bring up.
Just to completely verify, let's go back here to Wireshark,
and we can see here that there was
that last route-refresh message sent to populate the software
configuration table.
But after that, there are no more
even though we did the clear two more times.
They're not here because they were soft reconfiguration.
And just like on iOS XR, go back over to router 7.
We can see that received table here as well.
If we do a show IP BGP neighbor for the 50.0.167.1,
we can do received routes.
Here we can see the table that we received from router 1.
So we can see that this is working exactly as we expected.
In this video, we took a look at how iOS XR and iOS
XE behave in regard to soft reconfiguration
inbound versus route-refresh.
We saw that both of them will do route-refresh by default,
but, of course, we can enable the soft reconfiguration
inbound.
The interesting thing to take away from this,
though, is even if you enable soft reconfiguration inbound
on iOS XR, it actually won't do it if the neighbor itself
supports route-refresh, so you have to actually force it
by saying always.
I hope this has been informative for you,
and I'd like to thank you for viewing.