[AUDIO LOGO]
Next up, we have Trouble Ticket 3.
And this ticket simply says that routes being injected into BGP
on R10, so coming down this way, are not reaching router 7,
and they should be.
So we're going to have to go look at router 7
and find out why it's not getting prefixes
from router 10.
So let's jump into the command line.
Of course, we might as well start on router 7.
Let's start with a show ip bgp.
And as we can see, we do have a network
coming from router 8, which is one of our other neighbors,
but certainly nothing coming from router 10 or router 6
or router 1 or router.
We're just getting one update coming from router 8.
So let's see if we configure what's going on.
Let's start by going to router 6 and see
if router 6 is even trying to send anything to router 7.
Keep in mind, the reason we're looking at router 6
is we don't know if the problem yet is router 10 or router 6.
So we may, as well, just go to router 6 and see what it knows.
So first on router 6, let's do our show ip bgp,
and we see that this does in fact have prefixes
being learned from router 10.
So clearly, router 6 does have the prefixes.
Now, let's see if it's sending them to the neighbor.
So we'll say show ip bgp neighbor 50.0.167.7,
and we'll say advertised-routes.
So according to router 6, it is, in fact,
sending all of these prefixes to router 7.
But for some reason, router 7 is not getting them.
So let's actually jump on to Wireshark real quick
and see if router 6 is actually sending them
or if it just thinks it's sending them.
So here in Wireshark, we're going
to capture on router 7's gigabit 1 interface,
and we're filtering four BGP packets except for BGP packets
with a length of 19.
That's to prevent the keepalives from showing up and making
this more difficult to find the packets we're looking for.
So now, let's go to router 7 and do a clear on our BGP neighbors
and see what gets sent.
We'll just do a clear ip bgp star in.
And then let's go back and see if we've picked up anything
on Wireshark.
So here in Wireshark, we actually
see this packet that is an update coming from router 6
to router 7.
We can see that this is in response, actually,
to a route refresh message.
But let's take a look at what's in here.
Let's expand the update message.
We'll start with the first one and look at the NLRI.
We see here where it was trying to advertise
all of these subnets coming from router 10.
These other update messages are going to contain other NLRIs,
but we don't really have to look at every one of them.
We see that router 6 is, in fact, sending updates
to router 7 with this information.
So let's go back and look at router 7 again.
So since we know that router 7 is, in fact, receiving
the updates, let's debug those updates.
So we'll turn on terminal monitor,
and we'll do a debug ip bgp update.
Then let's do a clear ip bgp, but this time, only the
router 6.
That way, we don't get other packets from other routers
because there is router 1 out there.
So let's go ahead and clear this.
Let's turn off the debugging because we've already
seen what we need to see.
Let's scroll up just a little bit.
This way, we can see the bulk of the messages.
All of these messages right here are
about receiving all of those prefixes.
And notice, it says denied due to the AS path
contains our own AS.
So as we can see, this is just standard BGP loop prevention.
BGP will not accept updates if its own AS is in the AS path.
And if we look back at our diagram,
we can see clearly here that router 10 and router 7
are in the same AS.
And as such, router 7 is not going
to be accepting these updates.
So we have a couple of choices on how we can fix this.
The first would be, we could do remove private AS on router 6.
We would have to do remove private AS all
because otherwise, it won't remove the private AS when
we send back to our own AS number,
or we could do maybe local AS on router 7.
Change router 7's configuration to actually use a different AS
number.
There's a lot of things that would
be involved in doing that, but it could certainly be done.
Or of course, we could always just change the AS numbers.
That's, of course, an option.
Or we could use something called allowas-in.
Now, the problem with using allowas-in
is we are basically disabling or circumventing BGP's normal loop
prevention.
So if we're going to do that, that leaves it up
to us as administrators to make sure we're not creating a loop.
Now, we can tell clearly by looking here at the diagram
that allowing these routes from router 10 into router 7
would not cause a loop in this particular environment.
So as long as we know it's not going to create a loop,
that would be a fair thing to do.
So let's go ahead and go back over to router 7
and figure out which solution we want to implement.
So given our different choices, if we
have to implement the solution just on router 7,
we're going to have to go with that allowas-in option.
So let's go into Configuration mode, router bgp 65001.
For the neighbor, 50.0.167.6.
We're going to say allowas-in.
I don't know about you, but I've always
found this command a little bit interesting.
Why is it allowas, like it's one word, dash in instead of like,
allow-as-in?
Might make a little more sense.
The command is what it is.
I've just always personally found it a little bit amusing.
We can then specify how many times
we want to allow our AS in.
I'm not going to specify this, so we can see the default.
The default is actually 3.
The reason for this, of course, is in case
our update is going around and around in a loop,
it doesn't loop forever.
So yes, we're disabling loop prevention, but with a limit.
So we'll just say allowas-in, so we can see what it does.
This is not something we actually have
to clear the neighborship for.
If we do a show ip bgp, we can see
that they've already shown up.
If we do a show ip bgp for the neighbor 50.0.167.6
under the address family, we can actually
see here where we're allowing our AS number in.
And well, it's not exactly proper English,
but I didn't write it.
My AS number is allowed for three number of times.
So that's what it says.
But of course, the point is, it's
allowing our AS in three time.
And of course, as we just saw, we
are now getting the prefixes that we're supposed
to be getting on router 7.
So that proves that we have, in fact, solved this ticket.
In this video, we saw an example of a problem with BGP AS path,
where we had a device not accepting prefixes
that we wanted it to because they
had our own AS in the AS path.
Now, again, there's a couple of different ways to fix this.
One that I actually didn't mention in our choices
is something called as-override.
We'll take a look at that one a little bit more
in our MPLS section.
But there's a couple of ways we could have fixed this,
but one of them is to allow AS in.
And of course, we can limit how many times it
does that, the default being 3.
I hope this has been informative for you,
and I'd like to thank you for viewing.