[AUDIO LOGO]
So in this video, we're going to be
verifying and troubleshooting our confederation environment.
Now, we already got a little bit of a hint in our last video
that something's not quite right as it is at the moment.
We saw on Router 7, just as an example,
that some of the prefixes were missing.
I think one of the prefixes didn't
have a best path selected.
So there's definitely some issues going on.
Now, to approach this we're going
to use a slightly different method here that we're
going to jump to the command line
first, take a look at what's going on, and then come back
and look at our topology diagram and see
if we can figure out why and what we need to do to fix it.
Then, of course, we'll implement any necessary fixes
and finally verify it to make sure
that it's working after that.
So let's go ahead and jump into the command line.
We'll start by looking at Router 1
and see what prefixes it's currently aware of.
So let's just start with a show IP BGP.
The first thing we want to see here
is Router 1 does in fact have all four prefixes.
But even though it has all four, notice
that it's only selected a best path for the 100.4.4.0
and the 100.9.9.0.
The other two prefixes, coming from AS 65002
and then from the external AS is beyond that,
they have no best path selected.
So let's look at one of those in more detail.
Let's do a show BGP for the 100.8.8.0,
and we can almost immediately see the problem.
The next hop of 192.168.78.8 is inaccessible.
If we do a show IP route, we have no route
to the 192.168 networks.
So of course Router 1 doesn't know how to get there.
It's an inaccessible next hop.
Let's hop over and look at Router 7,
since we already know it was having a problem.
Again, if we do our show IP BGP, it actually
only has two of the prefixes.
So let's look at the one that it has but again
hasn't selected as best.
And if we look at the 100.10.10.0,
we can see that this is also inaccessible because the next
hop is 10.
So hopefully we're beginning to see a trend here.
Let's hop over to the diagram and take a look
at what's going on.
Thinking about this from Router 1's perspective
and talking about that prefix that we looked at earlier,
which is Router 8's loopback.
When Router 8 advertises that prefix to Router 7,
the next hop on that prefix is going
to be Router 8's address on this 192.168.78 network,
and that happens to be 8.
8.
That's Router 8's host address.
When Router 7 advertises this through iBGP up to Router 6,
it leaves that next hop the same.
Then Router 6 advertises it over to Router 1
and it also leaves the next hop the same.
This is why Router 1 is receiving it
with the next hop of Router 8's interface way
down here on this network.
That's just an example of why these next hops are
inaccessible.
In an environment like this, we're
going to have these next hop issues all over the place
because almost all of these prefixes
are being sent between devices that are in confederation
peers, and with confederation peers,
we treat those updates from a next hop perspective like iBGP.
The thought process there is, well, the underlying IGP
should be handling how to get to all the next hops.
But in this case, remember that we're running OSPF and ISIS
in AS 65002 and AS 65001, running nothing
at all in AS 65003, so none of these devices
know how to get to any of the next hops.
So there's really two choices on how to fix this.
Choice number one would be switch out the IGP
or redistribute or add a new IGP.
Do something so all of the routers
know how to get to all of the next hops.
That could definitely be done.
The other choice is we're pretty much
going to have to do next hop self everywhere
that there's a connection between the confederations.
So that's the approach we're going to take.
I'm going to show you on the first couple of routers,
and then we're just going to go ahead and copy and paste
it and all the other ones because there
is a lot of next hop selves that we're going to have
to do here to get this to work.
So let's jump in and do that.
So here on Router 1, we're going to have
to do next hop self to all of our iBGP peers
as well as to Router 9 and to Router 6,
which is pretty much all of its neighbors.
So we'll just go ahead and paste the configuration in here
to do this.
As you can see here if you look over this quickly,
all we're doing is going into the neighbor
group, iBGP peers for the address family IPv4,
turning on Next Hop Self.
Then we're doing the exact same thing
for our neighbor, which is Router 9 ending in the .9,
and our neighbor, which is .6 ending in the .6.
So that's all we have to do to configure Router 1.
Let's go to Router 2.
And again, we're trying to make this not just about typing,
so we're just going to copy and paste this.
Once again, this is going to be very repetitive,
but on Router 2 it only has to worry
about Router 1 and Router 9.
So that's a fairly straightforward configuration.
On router 3, it only has to deal with Router 1 and Router 7.
So that takes care of that configuration.
Router 4 only has to do it towards Router 1.
Router 5 doesn't really need it because it's not
injecting any routes, but let's put it
in there just in case Router 5 needs to inject some routes.
Router 6 needs to do router 7 and Router 1,
Router 7 needs to do Router 6 and Router 3,
and Router 9 needs to do Router 1 and Router 2.
So that was a lot of configuration.
I know we went through it very quickly,
but if you need time to catch up,
just go back and review the video a little bit.
Pause on each screen if you need to to see
the actual configuration that we put into each device.
So now let's do our verification again.
So now let's go back over to Router 1.
Let's do our show IP BGP, and notice
that now we have all of the prefixes
and they all have a chosen best path.
So this is looking a heck of a lot better.
Let's check that 108.8.8.0 prefix again.
So notice that we're now receiving it.
It has a valid next hop, in this case Router 6,
and also notice that it's marked as confed-external, indicating
it's not from this AS but from a confederation peer.
We could also look at Router 9.
We see that we're getting two paths, one from Router 2,
which is confed-internal.
It's coming from our same confederation, 65001,
and the one directly from Router 9, coming from, of course,
65003, which is confed-external because it's outside of 65001.
So let's go do a show iBGP on each of our devices
just to make sure they have all the prefixes.
We'll go through this fairly quickly.
We see here on Router 2 that it has three of the prefixes,
but it's missing the one from Router 4.
That's a different problem that we'll
be addressing in the next video, where we have to configure
our route reflector.
But for the three paths that it is learning,
it has a best path for all of them.
Let's look at Router 3.
3 pretty much the same situation as Router 2.
Let's look at Router 4.
Router 4 we can see has all four prefixes.
Now, that's, of course, because Router 4 is in fact injecting
one of them, but it also has the three
that it needs to be learning, and it's
learning them from Router 1.
Router 5, same situation pretty much as routers 2 and 3,
except it's a little bit different
because it only has that one next hop going to Router 1,
but it's learning the three prefixes it needs to.
Still not getting that one from Router 4.
If we look at Router 6, it's learning all four prefixes
and each of them has a best path selected.
Router 7, same thing, learning all four and all four
have a best path.
Also note as we're going through here, the AS path.
Notice that these are carrying the internal confederation
AS numbers in parentheses in the AS path.
This, of course, is how the confederations
do loop prevention within the overall confederation
between the sub ASes.
We're going to jump here out to routers 8 and 10
and look at how they see these prefixes as well,
and what we want to notice as we're looking at those
is that these internal confederation
ASes are going to disappear out of the AS path, and, of course,
they should.
So here on Router 8 when we do our show IP BPG,
we have all four prefixes.
Everything looks good and there's no confederation ASes
in the AS path.
Router 9, once again looking good.
All four paths and a best path selected for each one.
And finally, of course, Router 10, and it has all of the paths
appropriately as well.
So in this video, we had to troubleshoot and verify
our confederation environment.
And as we saw, our main issue was
we had a lot of next hop self issues,
or really, next hop reachability issues.
We could have fixed that, of course,
in a few different ways.
We did next hop self.
Again, we could have changed it by doing the IGP or, honestly,
we could have changed it with a route map
or routing policy language, and actually
just changed the next hop on updates as we were sending them
to our neighbors.
That's usually not necessary, because that's more
if we need to set a next hop on specific prefixes,
and in this case, we just had to set the next hop
on all the prefixes we were sending to a neighbor.
But keep in mind, we can do it on specific prefixes
if we need to.
So where we are right now is everything's working
perfectly except Router 4's loopback inside of AS 65001,
and the solution to that is going
to be a route reflector, which we're going to set up
in the very next video.
I hope this has been informative for you
and I'd like to thank you for viewing.