[MUSIC PLAYING]
Moving on now to Trouble Ticket 4.
This one is about R2 and R9.
So it's saying that R2 and R9 are supposed to be neighbors,
but they are currently down.
So as per usual, let's jump over to the command line
and see what's going on with this neighborship.
So we'll start here on Router 2 with our typical show IP BGP
summary--
great command to start with when we're troubleshooting BGP.
And what we see is we have this 50.1.29.9, which is currently
in an active state.
Now, since it's active, that tells us
that we have a route to it, which we should,
because it's a directly connected interface.
But let's verify that we actually have a connection,
and that it's working.
Let's go ahead and ping that neighbor.
So 50.1.29.9.
If we ping it, we can see that that's successful.
So it appears to be working.
So just at first glance here, this
appears to be working properly.
Let's go see what's going on on Router 9.
Once again, let's do our show IP BGP summary.
And what's interesting about this output is we can see that
we have a BGP peer group, PG_AS100_Peers,
that looks like it's tied to a listen range of 50.1.0.0/16.
Also, it has no neighbors in that listen range
because nothing's listed here.
So if we do a show run section BGP,
we can see pretty much what we suspected.
Here we have our listen range, which matches what our show IP
BGP summary showed us.
It is in fact tied to that peer group.
The peer group does exist.
It's been configured.
It's got the remote AS configured.
It's got a password configured.
And it's originating a default route.
Now, originating the default route
is not going to have anything to do with this ticket.
The remote AS is correct.
But let's keep in mind that there's a password set here.
Maybe that is going to become important.
Always good things to know.
It's also not necessarily a bad idea,
depending on your terminal software,
go ahead and highlight that password,
and just make sure there's no extra spaces
or anything like that, that we can't easily
see right on the text output.
In this case, of course, it appears to be fine.
So like always, when things generally look OK,
never a bad idea to fire up Wireshark
and see what these packets look like on the wire.
So let's do just that.
So here's our Wireshark capture.
It is filtered to match on TCP or BGP.
Notice that the very first packet that we captured here
is a TCP send request.
But notice that it's going from the source of 10.2.2.2
to 50.1.29.9.
So it's going from Router 2 to Router 9,
but it's being sourced from Router 2's loopback.
The reason that's a problem is, remember the listen range
that we just saw on Router 9.
Router 9 is configured for a listen range
that matches the physical interfaces, not the loopbacks.
Plus, Router 9 may not even have a route
back to Router 2's loopback.
We're not running an IGP with Router 9
in this lab environment.
So for a couple of reasons, that could be problematic.
And we see that because of this, we're never even completing
the TCP three-way handshake.
It's sending the send request.
And then what do we see after this?
Just retransmission timeouts as it keeps trying,
but it's not getting anywhere.
Now, one interesting thing we could check while we're here
though, is since we know there's a password,
we could check if Router 2 is at least
trying to send that password.
Let's see if we can see it here.
So if we open up TCP, and then we scroll down,
then we open Options, we can actually
see right here that the TCP MD5 signature is
attached to these packets.
So what does all this tell us?
It tells us that Router 2 looks like it's
configured for a password.
Now, let's not kid ourselves.
That password could, of course, still be the wrong password.
Nobody says that password is actually correct.
But it is setting an MD5 password in option 19,
like it's supposed to.
It's just sourcing the packet from its loopback instead
of its physical interface.
So let's jump over and take a look
at that configuration on Router 2.
And I'm betting that's what we're going to see.
So if we do our show run router BGP,
and we look here at our neighbor 50.1.29.9,
we see exactly what we suspected.
First, yes, it has a password.
Of course, it's shown encrypted here.
So we can't easily tell if it's the correct password.
If we weren't sure, we could just try to put it in again.
But more importantly, we see this update source loopback 0.
That should not be there.
So it does appear that we have found
the issue here on Router 2.
As usual, we have to decide how to fix it.
So there's really two choices in this case,
that are relatively easy.
One of them would be to simply change
the listen range on Router 9, and actually
peer up using the loopback.
We've already discussed the problem with that though.
Router 9 doesn't have a route back to Router 2's loopback.
So, yes, we could do it that way,
but then we'd have to configure something like static routing,
or fire up an IGP, maybe bring Router 9 into our existing
IS-IS routing domain.
We would have to do something to allow that to work.
Or, optionally, we could just pair these up
on their physical interfaces, which
given this neighbor statement here on Router 2,
and the listen range on Router 9,
it sort of looks like that's how this was intended to work.
These look like they were intended to work
on their physical interfaces.
So in that case, I think we should just take out the update
source loopback 0 on Router 2.
That's probably our best solution.
So let's do that.
We'll simply go into configuration, into router BGP
100, into neighbor 50.1.29.9, and say no update source
loopback 0.
We'll commit that change and our configuration.
And if we give it just a moment, that neighborship
should come up.
So I gave it a few seconds, let's check.
Show IP BGP summary.
And we can see that Router 9 is now up properly.
It's been up for 41 seconds.
Let's, of course, verify this on the Router 9 side as well.
Although, I'm sure it will agree.
So again, show IP BGP summary.
And we in fact see that 50.1.29.2 is in fact up.
It's been up for a minute and 2 seconds.
We've received eight prefixes from it.
And notice the asterisk on the front of this,
that it's learned through a dynamic listen range, which
also means that it's a member of our peer group PG_AS100_Peers.
So now that it's up and running, if we do a show IP BGP,
we should see that we are, in fact, getting prefixes,
and we're injecting a default. We
could also verify that that default is showing up properly
on Router 2, just to make sure we're fully
exchanging prefixes.
So let's do a show IP BGP here.
And we see, in fact, that we do have that default route that's
being sent from Router 9.
So with the neighbors up and the prefixes being exchanged,
that's pretty good proof that we have solved this ticket.
So in this video, we saw a problem pretty much directly
related to one of our routers having the incorrect source
address configured to send its BGP connections.
Now, update source loopback 0 isn't a bad command, of course,
if you're actually trying to peer with loopbacks.
But in this particular case, we weren't.
One router was configured to peer with physical addresses,
the other one was set to peer with loopback.
And of course, it really doesn't matter which one we choose,
as long as we have the underlying routing.
It's just that both sides do need to agree.
I hope this has been informative for you,
and I'd like to thank you for viewing.