I've got the virtual lab fired up here.
I am ready to solve some BGP problems that I admittedly
created and forgot what I did.
So we are trying to get all the way from R1 over the topology
down over to R10 here.
Pinging from-- nope--
over here.
10.10.10.10 to 1.1.1.4.
I guess the flip side of it would be true, because you
have to have return traffic.
But let's just start from our source
and see what goes on here.
So from R10, I'll give it a show ip interface brief. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from R10, I'll give it a show ip interface brief.
I see that my loopback of 10.10.10.10 is up.
That's a good start.
Let's ping 1.1.1.4 sourced from loopback 1.
Traffic is definitely dead here.
There's no art timeout followed by four successful bangs.
So let's just try this.
Let's trace and see where it's dying.
We'll do trace to 1.1.--
nope-- 1.1.1.4.
And it's totally hosed here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's totally hosed here.
If I give it a show ip route, do I even have a route to--
I don't even have a route to 1.1.1.4.
Well, that could definitely be a problem.
So let's go ahead and hop over to R1
to make sure that it's even advertising the route.
So let's make sure R1 is even advertising the route.
If I give it a show ip interface brief,
I can see that I do have loopback 4 here
and it's in an upstate.
I've only got the one outbound IP address.
So I'm pretty sure that's going to be my neighbor if I give it
a show ipv4 unicast summary. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a show ipv4 unicast summary.
We'll make sure.
Yeah, it looks like my neighbor relationship
is alive and healthy, because I've
received one prefix from them.
So let's just make sure that I'm advertising this route
towards our neighbor.
I'll give it a show bgp ipv4 unicast neighbor
172.16.12.2 advertised-routes.
Ah, OK.
Well, there's a big reason right there.
We're not advertising the route.
Why are we not advertising the route?
I'll give it a show run.
We'll pipe that to section bgp. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll pipe that to section bgp.
And it's because we're literally not advertising the route.
There's no network statement that has identified the 1.1.1.4
network.
So let's jump into configuration mode.
Hop down into router bgp 100.
Nope, not route bgp 100.
Router bgp 100.
And let's specify our network of 1.1.1.4.
The mask of 255.255.255.255.
Press Enter there.
And we'll jump out of configuration mode.
If I hit Up a few times here-- let's make sure that
the advertised route-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the advertised route--
there it is.
Now we're advertising the route.
So if I jump over to R2 do I now see that route in my BGP table?
I do see it in my BGP table.
So that means it should be advertised
throughout the entire network all the way up to R10
at this point.
Let's do a show ip route.
And I do see that I now have a route to 1.1.1.4.
So now if I do trace route, 1.1.1.4,
I'll specify my source one more time WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll specify my source one more time
because we did want to do this from the loopback.
So it makes it to router 8 here, and then dies.
Recall that the topology here was R10, then to R9, then
to R8.
But there is a confederation link to R7 or to R5.
R6 was in the middle serving as a route reflector.
So it makes it to R9.
It tries to hop to R8.
And then it dies.
So there's either something wrong right here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's either something wrong right here,
or there's something wrong right here at this point.
Clearly, there's something wrong with my confederation.
So let's stop our trace route running here.
Jump over to R9.
And here's what I want to do.
I want to check out my show bgp ipv4 unicast just
to make sure my BGP table looks good and healthy.
I'm definitely receiving routes from the confederation 65,100,
but they look to be coming from the link between R5 and R8.
I'm not seeing a link between R9 or R7. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm not seeing a link between R9 or R7.
I would expect to see advertised routes coming from that path,
too.
So if I give it a show ip interface brief,
I would expect my link to be coming from 10.0.79.7.
So let's check out show bgp ipv4 unicast summary
to see if we have a neighbor relationship there.
OK.
The plot thickens.
My neighbor of R7 is in an idle state.
Let's just check out the running config here.
Let's just do show run section bgp. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's just do show run section bgp.
And make sure that the confederation
was configured correctly on this router for R7.
The confederation looks good here.
I see I've got my confederation identifier,
my confederation peers being that other autonomous system,
65,100.
And then my two peers specified here.
If I jump over to R7, I'm going to do the same thing.
I'll do show bgp ipv4 unicast summary.
Ah, peculiar.
I'm not seeing a neighbor relationship between me
and R9 at all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and R9 at all.
Let's do show run section bgp.
Oh, you know what?
There it is.
It's those address families.
You see the configuration here, right there, that line.
We denied the default setting that makes our commands default
into IPv4 unicast.
So when this command is issued, there's
no bgp default ipv4 unicast.
When you issue the neighbor command,
you then have to go into the address family section WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you then have to go into the address family section
and actually activate that address family's feature
for each neighbor.
If we don't activate IPv4 unicast routing
for this neighbor, in this case, R9,
it's not going to try and build that relationship.
So if I do show bgp ipv4 unicast neighbor 10.0.79.9,
it says there is no such neighbor.
And that's because it's not even trying to activate
that connection to them.
So let's go into configuration mode, router bgp
or confederation member AS is 65,100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or confederation member AS is 65,100.
I'll go into the address family for IPv4.
And I'll say neighbor 10.0.79.9 activate.
Look at that.
The neighbor adjacency has come to life.
Let's jump back to R10 now and try and perform
that trace route one more time.
OK.
It looks like it.
Oh, yep.
Look at that.
It made it there.
Some dead traffic along the way.
And right when I was about to pull the trigger and say, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And right when I was about to pull the trigger and say,
this didn't work, it did.
It made it there, but did it use the optimal path
of our gigabit Ethernet link?
It did not.
It went down that fast Ethernet link right there, which was R2.
So a little bit more troubleshooting left to go.
We're really close.
We do have return traffic.
That's great news, but it's not taking the optimal path.
So let's jump over to R4, R3, and R2,
and try and figure out why are R4 sent the traffic
down the fast Ethernet link.
I really don't remember what I did here, so this is good WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I really don't remember what I did here, so this is good
troubleshooting for me.
Let's do show bgp ipv4 unicast and see what
we've got in our BGP table.
It looks like I'm not receiving any advertisements from R3
at all.
That would be a problem.
Let's do show bgp ipv4 unicast summary
to see if I even have a neighbor relationship there.
Yep.
I do have a relationship there, but I'm not
receiving any prefixes from R3.
So these prefixes, 1.1.1.1, if I'm drawing it out, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So these prefixes, 1.1.1.1, if I'm drawing it out,
they start at R1.
They went to R2.
They should have gone over to R3, who then would
have advertised them up to R4.
But it looks like there are no prefixes being advertised over
from R3.
So did R3 even receive these routes at all?
That's the next big question.
Let's go to R3.
Do show bgp ipv4 unicast.
Nope.
R3 didn't receive these routes.
So what would have caused R3 to not receive these routes? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what would have caused R3 to not receive these routes?
My head goes towards route reflectors.
R2 should have been a route reflector.
And R1, or R3, or both should have been clients.
And it would have reflected those routes over to R3.
So if I jump over to R2 just to verify,
I'll do a show run section bgp.
And I do not see any route reflector configuration here
at all.
A quick fix to that, let's go into router bgp 100. . WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
A quick fix to that, let's go into router bgp 100. .
Neighbor of 172.16.12.1 route reflector client.
Hit Enter.
Back out of this.
Looking a lot better at this point.
If I jump down to R4, let's issue the summaries again.
Ah!
Now I'm receiving prefixes from R3, which is great news.
If I jump over to R10, we'll issue the trace route one more
time.
Looking much better. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Looking much better.
Now it jumped down to R3 over to R2, then to R1.
And our troubleshooting has been completed.
Let's take a look.
We had issues with confederation.
We had issues because the address family had not been
activated for one of our peers.
We had a route reflector issue on R2.
And R1 wasn't even advertising the route in the first place.
So that's been our first troubleshooting scenario.
Buckle up, because we're going to have
a lot of fun in the next one.
In the meantime, I hope this has been informative for you.
And I'd like to thank you for viewing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I'd like to thank you for viewing.