- In our previous video we took a look at ether channels;
it was a bit of review from our CCNA studies.
Now in this video we want to take a look at how to
trouble shoot an ether channel that's not working correctly
by taking a look at some common issues.
And then we're going to go through a troubleshooting
scenario together.
One of the most common reasons that an ether channels
not behaving as expected is the ports at each end of
a link that's part of an ether channel;
they're configured differently in terms of maybe speed,
or they might have a different duplex setting.
Or a different trunk mode, or they might be configured
for a native VLAN.
Or they allow a different set of set of VLANS.
After all, we typically are going to be setting up a
trunk over an ether channel because an ether channel gives
us nice big pipe of bandwidth.
That's a great place to configure a trunk because a trunk is
carrying traffic for multiple VLANS.
It potentially needs a lot of bandwidth.
Another issue we could run into is,
we've got a misconfiguration in our PAgP or LACP settings.
Remember PAgP; that's the port aggregation protocol.
That's the cisco proprietary protocol that will allow
us to form a channel and allow a link to join an ether
channel bundle.
And if we're set to on, on either side, then we're not
really running PAgP on that port; we're just on.
And if we're set to on, on one side, we need to be set
to on on the other side or else the ether channels not
going to be formed.
Desirable, however, it will send out PAgP frames
and if the other side is set either auto or desirable,
then an ether channels going to be negotiated and this
link is going to join an ether channel bundle.
If both sides are set to auto though, that's not going to work.
Both sides are willing to become part of an ether channel,
but nobody's initiating the sending of PAgP frames,
so it never happens.
It's almost identical, it's the same logic with LACP,
we just have different terminology instead of the auto mode
that we have with PAgP.
We have the passive mode with LACP.
And instead of the PAgP mode of desirable,
we have the LACP mode of active.
Yet another reason that we might have an ether channel
issue, is that we have a suboptimal configuration for our
load balancing algorithm.
Remember the scenario I walked you through in the previous
video, where we had this false sense of security that this
PC was load balancing over all these different links going
to a server farm.
And really every packet going to all three of those servers,
was using the same link on our ether channel
because it was based on the destination mac address.
And I suggested that we might want to make things a bit
more random by considering both the source and
the destination addresses.
Be those IP addresses or mac addresses.
And that way we'll take the last however many bits,
one, two or three bits of the mac address of the
source and destination or the IP address of the source
and destination.
And we'll do a boolean operation.
We'll do an exclusive OR operation
and that's what adds the randomness to our link selection.
Now, with this reminder of some of the different things
that could go wrong,
lets go out to a scenario where we have an ether channel
that's not behaving as expected and see if we can fix
the issue.
Here in this scenario, we've got an ether channel
set up between switches sw1 and sw2.
However, we've received a report that the ether channel
is supposed to be made up of four links,
but only three of those links appear to be working.
Only three links appear to be part of that bundle.
Let's confirm that first of all.
We can do that with a show
ether channel summary command.
And we see that we do have four links that are configured
to be part of this bundle.
However, notice the p and the i codes.
What do these mean?
Well, this p code or the p flag,
that means that this port is bundled in the port channel.
The i means its independent, its stand alone.
Its not part of the bundle right now.
Lets see how things look from the perspective of sw2.
Lets do a show
ether channel summary.
Same thing here, it looks like gigabyte one slash zero
on both sides has an i flag,
indicating that it is not part of the bundle.
That's our challenge.
How are we going to fix that?
Well, lets check out the configuration here on sw2
to see if we can uncover any clues.
We'll do a show run.
And lets look at those four ports
that are supposed to be making up that port channel.
And the first one is zero slash one.
Then we've got zero slash two,
zero slash three and zero slash;
actually its one slash zero.
Those appear to be identical in their configuration.
They're all set to a trunking mode of trunk.
They all have their PAgP mode set to auto,
meaning that we're expecting the other side to be desirable.
We expect the other side to send us a PAgP frame.
Lets try one other thing.
Lets do a show interfaces
trunk.
Look at this.
In addition to having the port channel port trunking,
we also have that gigabyte one slash zero port trunking.
So we know we've got a good connection between switches
sw1 and sw2 on gigabyte one slash zero.
But for some reason its not part of the channel.
Both sides from the output of our show ether channel
summary command indicate that that port is told to be
part of that channel group,
but its not.
Based on what we've seen here on sw2,
I don't see any misconfiguration,
so I'm suspecting somethings up on sw1.
Before we go on and go over to sw1,
you might want to pause the video right now and think about
what could possibly be going on.
There's more than one thing, but think for a moment about
what is a likely cause that
this single port in this ether channel is not joining
the ether channel.
All right, lets go take a look over on sw1.
Lets do a show run
and see if anything looks inconsistent with those ports.
We've got gigabyte zero slash one,
zero slash two,
zero slash three and one slash zero.
And you might want to pause the video
and study this for a moment.
I'm spotting something.
The PAgP mode for the first three ports is desirable.
The PAgP mode for the last port is auto.
Remember on sw2, everybody was set to auto.
Meaning that the other side had to be set to desirable.
It had to send out the PAgP frames saying,
Hey lets be part of this ether channel.
Well, here we're set to auto on gigabyte one slash zero.
I think that's the issue.
Lets fix that and see if that's going to resolve our symptom.
Lets go into global configuration mode
and then into interface gigabyte one slash zero
and we'll say,
channel hyphen group one mode.
And we're going to select desirable.
Lets give it a moment.
That interface is probably going to bounce.
Its going to go down, its going to come back up.
Looks like its already done that.
So lets see if it works now.
Lets do a show ether
channel summary command.
Look at this.
Gigabyte one slash zero now has the p flag
indicating that it is part of that channel.
And if we do a show interfaces trunk command again,
before we had the ether channel as a trunk and we had that
port of gigabyte one slash zero, it was also its own trunk.
Well here, gigabyte one slash zero isn't showing up
independently because now it is part of that
ether channel bundle.
So the issue was one of our ports on one of our switches
was set to an incorrect PAgP mode.