I'm back in the saddle again.
Our goal is essentially still the same.
We want to ping from R1 all the way through the topology over
to R10 using the loopback address 1.1.1.4 to 10.10.10.10.
But we've got a new set of problems in this scenario,
and again, I don't really remember what they were,
so this is going to be exciting and fun.
Let's just start from square one and verify that everything
is looking healthy on R1.
I'll give it a show ip interface brief.
Looks like we've got loopback 1.1.1.4, and it's up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Looks like we've got loopback 1.1.1.4, and it's up.
That's a good start.
Let's check out show ip route, see that I've got connectivity.
I don't even have a route to 10.10.10.10.
That's going to be a problem.
We're not even getting the network advertisement there.
So what my goal immediately thinks then is like, OK,
we need to go to R10 and make sure
that we're even advertising it.
I'll give it a show ip interface brief here
to make sure that it is up.
It is.
And our neighbor connection is going to be R9 here,
so let's make sure we're advertising it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so let's make sure we're advertising it.
I'll do show bgp ipv4 for unicast neighbor 150.150.90.9
advertised routes, and we are advertising it, OK.
From R10, I'll give it to show ip route
and I do see that I have a route towards R1
here, towards that 1.1.1.4.
So what I'm going to do is I'm going
to trace from here to 1.1.1.4--
nope, those are commas.
1.1.1.4, sourced from my loopback 1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1.1.1.4, sourced from my loopback 1,
and let's just see it dies.
OK, looks like it's going to die here at R8.
OK, so it's not making it through the confederation
yet again.
All right, I'll stop the trace route
there with the control shift 6, and we'll
start troubleshooting our confederation.
I'll take a look at R9--
oh.
Hello, R9.
We've got some BGP neighbor adjacency logs here going on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got some BGP neighbor adjacency logs here going on.
Getting a lot of passive resets.
Unsupported malformatted message received.
Hmm.
Ah, look at this right there, peer
in wrong autonomous system.
OK, well, that's peculiar.
Let's give it a show run section bgp
and see what we've configured here.
OK, it looks like it's configured correctly
on my side.
I've got my confederation identifier,
my confederation peers.
The remote AS here for R7 is indeed 65,100, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The remote AS here for R7 is indeed 65,100,
so let's jump over to R7 and take
a look at what's going on here.
If I give it a show run section bgp, ah, look at that.
I've got my confederation identifier,
but I didn't identify my confederation peers,
so that would definitely cause my confederation
to break down and blow up on me there.
So what I'm going to do is I'm going
to go into configuration mode router bgp.
The member AS for this confederation is 65,100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The member AS for this confederation is 65,100.
I'll say bgp confederation peers 65,200, which
is going to be R9's member AS.
I'll back out of this.
Ah, look at that.
Neighbor adjacency came up.
I'm getting no more nasty syslog messages.
If I go over to R10 now, can I now
successfully perform the tracer route?
Did that solve all of my problems?
OK, it does make it through the confederation.
Now it's sitting on R4.
Is it going to die here?
That is the real question.
It does not. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It does not.
That fixed our routability problem,
and we are now going all the way down to 172.16.12.1,
but it didn't take that optimal path again.
We see that 100.100.24.2, it's still choosing that fast
ethernet link, so there's something going on between R2,
3, and 4.
Let's jump over to R4 and take a look
at what the BGP table looks like.
Show bgp ipv4 unicast.
All right, we are learning routes from R3 and R2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, we are learning routes from R3 and R2,
but it is definitely preferring to send traffic
out R2's link down instead of R3.
I don't see any weights or local preferences configured here,
so that wasn't a factor.
Thinking about the BGP best path algorithm,
if nothing was manipulated, I think this literally came down
to the lowest router ID, which would have been
R2's loopback of 2.2.2.2, instead
of R3's loopback of 3.3.3.3, so that would have picked R2.
We could certainly use a route map
to manipulate that to force that traffic down through R3's link, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to manipulate that to force that traffic down through R3's link,
but remember, our goal was to get traffic
sourced from R1 up the link.
So let's actually take a look at R1's perspective
and see how traffic is flowing at this point.
Let's do show bgp ipv4 unicast.
OK, that's good news.
I do see that we have received the route for R10.
It is valid, it's best.
It was learned internally from R2, but notice this.
There is a local preference of 101 set here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There is a local preference of 101 set here.
So if I jump to R2 for a second and I do show route-map,
I do see that R2 has a match list for a prefix list called
the 10LocPres--
I'm assuming that's going to be the 10 subnet there--
and it's setting the local preference to 101.
Does R3 have anything, any trickeration going on here?
If I do a show route map, nope.
No route map here.
Does R4 have anything going on there too?
Let's do show route-map just to make sure
that it's just R2 that's manipulating this path.
Nope, no route map here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Nope, no route map here.
So what I would probably want to do
is I'd probably want to delete this local preference
or create a new local preference route map on R3.
Let's do that.
Rather than removing this local preference,
let's create a new local preference route map on R3
that would gain preference over that one in R2.
I'll do configuration terminal.
We're going to first create our prefix list.
I'll call this 10LocPref as here as well.
I'll say permit 10.10.10.10/32, because that's the prefix that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll say permit 10.10.10.10/32, because that's the prefix that
we want to match on.
I'll now go into route map.
I'll say R3LocPref will be the name of our route map here.
I'll specify a permit statement and sequence number 10.
I'll match ip address prefix list of 10LocPref.
We're going to set the local preference to be 200.
I'll then jump into the next sequence
by specifying route map R3LocPref permit 20.
That way, we don't stop the advertisement WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That way, we don't stop the advertisement
of any other NLRIs that are coming
in with that deny any that's at the implicit end of a route
map.
We'll exit out of road map configuration mode.
Router bgp 100.
Nope.
Router, again.
For my neighbor that is up on R4, which is 100.100.34.4,
we're going to specify the route-map of R3LocPref in.
I'll exit out.
I'll also give it a soft reset, clear bgp ipv4 unicast, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll also give it a soft reset, clear bgp ipv4 unicast,
specify my neighbor, 34.4 inbound, so that'll
start the soft reset process.
If I jump over to R2, let's see if it's taken effect on R2 yet.
We'll just take a look at the BGP table.
I do see the 10 route now has preference towards R3,
thanks to that local preference.
If I refresh my BGP local table on R1,
I now see that it also uses R3 for preference.
So if I give it a trace route, 10.10.10.10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I give it a trace route, 10.10.10.10,
sourced from loopback 4, which is that 1.1.1.4 address,
we are looking good.
It was sent over to R3.
We can see that happening here and here.
Then it made its way through the confederation here
and finally to the end result.
If I jump over to R10 does it follow a similar path
backwards?
It does not.
Why?
It was still preferred sending traffic down to R2.
So as it leaves AS 100, it's leaving correctly,
but as it's returning back, it's not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but as it's returning back, it's not
taking that gigabit link because R4 is still
preferring the link on R2.
So let's take a look at R4 here again.
Let's refresh our BGP table, and we definitely
see there's nothing that's manipulated
this prefix from choosing R3.
I think this is a great opportunity
to use those AS ACLs, because when
we receive a prefix from the autonomous system
100, no matter what it is, we want
to prefer traffic towards R3 over that gigabit ethernet
link.
So let's jump in and configure terminal. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's jump in and configure terminal.
We'll say ap-- ip as path--
I always get that wrong--
access list.
What are we going to give this thing in-- oh, we've
got to give it a number.
Let's just call it 1.
We're going to specify a permit statement and then what is
going to be our regex command.
Isn't that right?
Yep, absolutely.
I'm going to say starting with 100 space.
That means anything where the next AS path is 100,
I want it to prefer the gigabit ethernet link.
So I'll press Enter there to create my best path access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll press Enter there to create my best path access
list.
I'm now going to create a route map,
and I'm going to call this route map PrefR3.
We'll specify the permit statement, sequence number 10.
I'll say match.
I'll then specify just ip address,
because this is using an AS ACL.
I'll just say 1.
We're going to set the weight to be 100.
Then I'll create a route map for everything else.
We'll say route map PrefR3, permit 20.
That way, we don't accidentally block any advertised prefixes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That way, we don't accidentally block any advertised prefixes.
We'll exit out of route map configuration mode,
router bgp 200.
I'll specify my neighbor of 100.100.34.3 is going to have
a route map called PrefR3 inbound.
I'll exit out of router configuration mode.
I'll give it a show bgp ipv4 unicast.
Hasn't taken effect yet.
We'll do clear bgp ipv4 unicast, specify my neighbor
100.100.34.3 soft inbound clear. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
100.100.34.3 soft inbound clear.
Refresh my BGP table, and there we go.
Just like that, we've identified the AS ACLs,
so that it grabs anything where the next AS path is 100
and sets the way of 100 when that advertisement comes in
from R3.
So now if I jump back to R10, hit up one time.
Let's trace it.
Yep, now it's taking that gigabit ethernet link
down to R3, and our mission here in scenario 2
has been accomplished. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
has been accomplished.
So that's been troubleshooting BGP.
I hope this has been informative for you,
and I'd like to thank you for viewing.