[AUDIO LOGO]
So we'll start off here on Trouble Ticket 1.
And on Trouble Ticket 1, we're going
to be using BGP Topology 1.
Actually, all of these tickets are
going to use BGP Topology 1, so we
won't point it out every time.
But that is the topology that you
want to have convenient when we're
going through these tickets.
So what's the actual essence of this ticket?
Well, the tickets going to be listed down here at the bottom.
And the ticket is that router 5 is supposed
to have a neighborship to router 1 and router 2,
but they are down.
So router 5 is supposed to be peered up with R1 and R2.
But according to our ticket, this isn't working.
Now, another point of information
that you would hopefully be able to get out of documentation
if you didn't know this, but in our environment,
both of these routers are in fact route reflectors.
That's why router 5 would only be peering with router 1
and router 2.
So as we get in and look at this,
we'll see that it's not neighbors with routers 3 and 4
either, but it's also not supposed to be.
So let's go ahead and jump in.
We'll, of course, always start with verifying the ticket.
So that means we start on router 5.
So let's start off with the good old show ip bgp summary.
And what we see is router 1 is actually
listed as being active.
Router 2 is listed as being idle.
If we do the same command again, we see that they now flip-flop.
So both of these routers are cycling
between active and idle.
Now, one of the first things we want to check with BGP
is that we have reachability.
Now, we know that we have a route to the destination,
in this case, 10.1.1.1 and 10.2.2.2.
The reason we know that is it wouldn't even
be trying to go active if it didn't have the route.
So we could verify the route if we like,
but we should already know that it has one,
or again, it wouldn't even try to go active.
It would be sitting in idle the whole time,
but that doesn't mean we actually have reachability.
So that should be probably one of the first things we check.
Let's do a ping 10.1.1.1.
And we'll go ahead and source that from our loopback
since these are supposed to be peering using loopbacks.
We see that that's successful.
And we can also ping, too.
So we have connections between the devices.
This is not a layer 1, a layer 2,
or a layer issue from the perspective
of at least being able to ping.
So now would probably be a good idea
to go look at what the other routers are seeing here.
So let's go to router 1.
We'll do our show ip bgp summary here.
And in relation to router 5, we have an idle.
So let's check its configuration.
Let's just do a show on router bgp.
Looking at router 5 here, we see that it's
using the neighbor-group RRC, which stands
for Route Reflector Client.
And if we look at our neighbor-group RRC,
it does appear to be configured properly.
It's configuring the remote-as.
We have our update source set to Loopback0.
And then under our address family,
it is configured with a Route Reflector Client
and next-hop-self.
So fundamentally, this looks correct.
Let's go ahead and verify router 5's configuration,
as well, since we didn't look at that.
We'll just do a show run section bgp.
This is a fairly straightforward configuration.
It is definitely set to be neighbored
with 10.1.1.1 and 10.2.2.2.
They both have the remote as configured properly,
and they're both set to Loopback0.
So far, everything's looking good.
So why don't we do this?
Why don't we jump into Wireshark and take a look
if these devices are actually communicating with each other?
So here's a packet capture of the traffic on that Ethernet
segment.
And here, we have a packet.
Notice that it's actually coming from router 5's
physical address 172.16.35.5 going to router 1.
And also, notice that it's an ICMP message.
Now, the reason this is important
is look over under the Info section here,
it says communication administratively filtered.
So we're actually getting a message
from router 5 telling us that it's rejecting our traffic.
So every time that router 1 tries
to send traffic to router 5 and vice versa,
notice what's happening.
We're getting a lot of send messages.
We're getting SYN-ACK messages.
And then we're getting communication administratively
filtered.
So something is stopping this communication
from forming a TCP three-way handshake.
One side is going SYN-SYN-ACK.
The other side is just going SYN and staying there.
It's never even getting a SYN-ACK,
instead it's getting that the communication is
administratively filtered.
This sounds a lot like an ACL.
So let's jump into router 5 and see if it does in fact
have any ACLs configured on that router
because it really looks like this traffic is being blocked
based on our Wireshark output.
Let's do a show ip interface gigabit 1.
And notice right here, we have an inbound access list
called ACL filter.
Let's take a look at that access list.
If we look at this access list, we
see that it's permitting some things,
like web traffic, FTP traffic, SMTP traffic, and so on.
However, what it's not doing is permitting BGP.
It's denying everything else.
And based on the number of matches
we have there particularly in a lab, that would probably
indicate that we're getting a lot of denied traffic
on this interface.
We also actually want to see if this access list is applied
to gigabit 2 because router 5 has two interfaces that it
could be talking on.
But as we can see, that access list
is applied inbound on this interface, as well.
So this definitely appears to be the problem.
So it does appear that we may have actually found
an isolated the problem.
So then the question always comes up, how should we fix it?
Well, what are our choices?
Choice number one, we could definitely just remove the ACL.
That would certainly solve the problem
assuming the ACL is the problem.
We could modify the ACL to actually support
BGP to allow that traffic, or in this case,
we could even just change the direction of the ACL.
It's applied inbound right now.
If it was applied outbound, it wouldn't filter
the router's own traffic.
But that would also probably fundamentally change
what the ACL is there for.
So from a troubleshooting and design perspective,
I would look at this and say, well, obviously,
the ACL is there for a reason.
Somebody wanted it there.
It's supposed to be filtering traffic in the direction
that it's doing so.
So the best fix, at least I think so,
would be to add BGP to the ACL to allow it to come through.
So that's what we're going to do.
Let's go ahead and update that ACL.
So first, let's just get a quick reminder of what it looks like.
So this is the current status.
We'll go into Configuration mode.
We'll go into our access list.
And then we'll create a new statement.
And it really doesn't matter too much where we put this.
However, it's a routing protocol.
I would generally put it near the top.
So we will say line 5 is going to be to permit tcp from anyone
to anyone if it equals bgp.
Now, one downside to this is if we do a show ip access
list again, is now we have all of our numbers nice and neat
by tens except for this 5 that we just
had to stick at the top.
So one cool feature we can use if we want to,
and this is, of course, completely
optional, we can say ip access-list sequence,
put in the name, and then tell it what line number we
want it to start with.
So we'll say start with 10, and then
what number you want it to increment by.
We'll, again, say 10.
And what this will do is remember the list
so that when we look at it, it's now starting at 10
and going through 70.
By the way, also note that our tcp any any
equals bgp line line 10 already has 31 matches.
I'm going to guess.
That means our neighborships are probably up.
So let's do our show ip bgp summary again,
and we can see that they've been up
for about a minute and a half, give or take here.
And we've learned eight prefixes.
If we do a show ip bgp, we're actually
getting prefixes coming from BGP.
So this gives us verification that we have, in fact,
solved this ticket.
So in this video, we had a ticket involving BGP.
But at the end of the day, this one
may not have actually been directly related to BGP.
It was just affecting BGP traffic, therefore,
preventing our neighborships from coming up.
But this is the kind of thing we have to worry about,
particularly with inbound ACLs.
We have to make sure we account for routing protocols.
Now, one thing you might note, and you
may have to go back and look at the ACL again,
but it did not allow IS-IS, which is actually our IGP here.
Just a quick note on that, IS-IS runs on CLNS.
It doesn't run on IP.
Therefore, an IP access-list is not
going to effect IS-IS traffic.
That's why we didn't have to allow it.
But either way, this gets our BGP neighbors up and running,
and this solves this ticket.
I hope this has been informative for you,
and I'd like to thank you for viewing.