- [Instructor] In this video, we want to talk about
some common 802.1Q trunk troubleshooting issues.
One issue we might run into if we find our 802.1Q trunk
is not working appropriately,
is we might have an encapsulation mismatch.
In other words, we might not be running 802.1Q
on each end of our trunk.
And this can depend on which model
of Cisco catalyst switch that you're running,
but some models support
Cisco's proprietary trunking protocol
of ISL inter-switch link.
Now this was very popular many years ago on Cisco devices.
Cisco recommended it, but in more recent years,
Cisco has gravitated towards the industry standard of Dot1q,
but you might see ISL as an option.
And with ISL we have 30 bytes of header that's added
to every frame.
Specifically, there's 26 bytes of payload
and then four bytes of checksum on top of that.
So 30 bytes added to each frame.
That's not terribly efficient.
It's much more efficient to use the industry standard;
IEEE 802.1Q trunk as we talked about in our previous video.
Here, we're adding four tag bytes to every frame
as long as that frame does not belong to the native VLAN.
That's a lot more efficient than ISL,
but the point is with a trunk,
we have to be the same on both ends.
And typically in today's networks, that's going to be 802.1Q.
Another issue we might run into
is having a trunking mode mismatch.
Let's think about and review how trunks
can be dynamically set up using DTP,
the Dynamic Trunking Protocol.
And one mode we have is the access mode.
If we configure a Cisco catalyst switch port
for access mode, then we're saying
this is not going to be a trunk.
It doesn't matter what the far end is trying to do.
We're not going to be a trunk.
We are specifically an access port.
We're going to connect to one device that's living
on one VLAN and we're not going to be doing trunking.
Another option we could set is a trunk mode.
Here we're saying you are a trunk.
This is the exact opposite of access.
We're saying you, by definition, are a trunk.
It doesn't matter what the far end is doing, you're a trunk.
However, oftentimes we set up our ports to dynamically
form a trunk if the other side is willing.
We might have one side set to dynamic desirable.
And dynamic desirable says,
I'm willing to be a trunk
if the other side is willing to be a trunk.
And we're going to use DTP to determine that.
Specifically if we're set to the desirable mode,
we will be the initiator of the negotiation.
We will send out a DTP frame asking the other side,
hey, do you want to become a trunk?
And if the other side is set to a trunk mode, it'll respond.
If it's set to dynamic desirable, it'll respond.
Or if it's set to our next option, dynamic auto,
it will respond.
In either of those scenarios,
then we're going to bring up a trunk.
Now dynamic auto is a little bit more timid
than dynamic desirable.
It's willing to become a trunk,
but it's not going to initiate the negotiation of a trunk.
If the other side will send us a DTP frame saying,
do you want to be a trunk?
Then we'll respond and say, well, yes, I would like
to be a trunk, and a trunk will be formed.
But we're not going to initiate the formation of a trunk.
That means if both sides are set to dynamic auto,
even though they're both willing to become a trunk,
nobody's going to initiate that conversation
and a trunk is not going to be formed.
In fact, let's take a look at some
of the different combinations
and permutations we might have.
First of all, if one side is set to access,
which means we're not going to be a trunk,
it really doesn't matter what the other switch is set to.
We're not going to form a trunk.
If one side is set to trunk and the other side is set
to dynamic desirable, then yes, we will form a trunk,
because if we set a port to trunk mode, it speaks DTP.
It will tell the dynamic desirable port on the other end
that yes it's willing to become a trunk.
In fact, it is a trunk.
If one side is set to trunk and the other side is set
to dynamic auto, that will bring up a trunk
because again the trunk port, it will send out DTP frames
and the dynamic auto side will respond to that.
If both sides are set to a trunk,
then obviously we have a trunk
and if both sides are set to dynamic desirable,
they're each sending out DTP frames
and the other side responds
and yeah, a trunk is going to be brought up.
And if one inside is set to dynamic desirable
and the other side is set to dynamic auto,
yes, a trunk will be brought up here as well
because the desirable side is going to
send out the DTP frame and the auto side
will respond to that.
But the other scenario where we will not form a trunk
is if both sides are set to dynamic auto.
They're both willing to become a trunk
but nobody is initiating that negotiation.
Another common issue that we have
is different allowed VLANs configured on our trunk ports.
By default on a trunk, all VLANs are allowed,
but we may have configured pruning.
And pruning is going to specify which VLANs can be allowed
or denied on a trunk and this could help us with security.
Maybe we don't want some highly sensitive traffic
on one VLAN from going across this trunk
where it has no business going.
We can prune it off of that trunk.
And if we don't really need to send traffic
for whatever reason over a trunk,
then it can help performance
by just not sending that traffic
if it really doesn't need to cross the trunk.
So pruning is a good thing.
It can help us with security,
it can help us with performance,
but it needs to match on both sides of the trunk
or we can run into some issues.
Something else that needs to match on each end
of a trunk is the native VLAN.
Remember that a native VLAN is that special VLAN
within a Dot1q trunk that does not add
those four tag bytes to a frame.
It's an untagged VLAN.
There's no VLAN identifier.
Whatever the native VLAN configuration of the switchboard,
that's what determines the native VLAN.
And by default, it's going to be VLAN 1,
but for security purposes,
a lot of people would like to change that native VLAN
from VLAN 1 to something else, maybe VLAN 199.
And if you do that,
you want to make sure that it matches on both ends.
In fact, if you don't match on both ends,
you'll typically get an error message
appearing on your console.
If you're seeing console messages pop up
on your command line interface terminal,
so that might be an easier one to troubleshoot
because you'll specifically be told
that you've got a native VLAN mismatch.
Now, let's go out to a topology that I have configured
and we've got a troubleshooting issue
that we need to resolve together.
Let's go check it out.
In this scenario, we want to have a trunk
between switches SW1 and SW2,
but we've got to report that it's not working.
Even though our network administrator claims
that both ends are being configured for trunking,
it doesn't seem to be working.
Now we need to go in and troubleshoot this
and resolve the situation.
And when we begin our troubleshooting efforts,
it's a good idea to see the issue for ourselves.
That way we'll know when it's resolved.
So let's begin on switch SW1
by doing a show interfaces trunk command
and nothing comes back. Okay, it doesn't know about a trunk.
Does switch SW2 know about a trunk?
Let's do a show interfaces trunk.
Nope, it does not know about a trunk either.
This confirms the reported issue.
Neither switch has a trunk.
As a next step,
let's gather some information using a show command.
Let's go back to switch SW1
and let's issue the command show interfaces.
And I'll give the interface identifier.
You see on the topology, gigabit 0/1
and then we'll give the keyword of switchport.
And I'll let you maybe pause the video.
Look at this output as I scroll through
the remainder of the output.
And without giving any commentary right now,
I want you to maybe pause the video,
study what's on screen
and then I'll give the same command over on switch SW2.
All right, let's go take a look at SW2.
We'll do a show interfaces
gigabit 0/1 switchport command.
And again, you might want to pause the video.
You might want to rewind the video
and see what we had on switch SW1.
Compare those two output screens
and I'd like you to hypothesize what you think
might be going on in this case.
All right, hopefully you've had some time to pause the video
and study the output.
Now let's walk through it together.
We saw over on switch SW1
that the administrative mode was dynamic auto,
but the operational mode was static access.
Well, administrative mode shows our configuration,
or in this case, dynamic auto on this particular switch,
that's the default configuration.
Now the operational mode shows what we're doing right now.
So we're configured, it's the default configuration,
but we're configured for dynamic auto
where we will respond to DTP frames,
but currently we're an access port.
Okay, that's an issue.
Let's see what the administrative
and operational modes are over on switch SW2.
Well, we have an administrative mode of dynamic desirable
or that sounds correct, doesn't it?
The dynamic desirable side should send DTP frames
over to the dynamic auto side,
which will then respond to those DTP frames
and bring up the trunk.
But currently, we're operating as an access port,
not a trunk port.
So something else is wrong.
It's not our switch mode configuration that's wrong.
So let's look a little bit deeper.
Let's go back over to switch SW1
and study some more of the output.
We talked about making sure that the native VLANs matched,
and if you remember from switch SW2,
we had the default native VLAN of VLAN 1, so that's fine.
We're not pruning off any of our VLANs on either switch.
They're all enabled.
But did you notice this?
The administrative trunking encapsulation on SW1 is ISL.
However, over on switch SW2,
the administrative trunking encapsulation is Dot1q.
We've got an encapsulation mismatch
and that would definitely prevent a trunk from forming.
So let's fix that and see if that resolves our issue.
To do that, and I'm going to go with Dot1q,
that's the preferred encapsulation method.
I'm going to go over to switch SW1.
Let's go into global configuration
and then I'll go into interface configuration mode
for gigabit 0/1 and I'll give the command switch port,
trunk, encapsulation, and with context sensitive help,
we see that we could negotiate, if we don't specify it,
we could negotiate the trunking encapsulation to use,
or we could say ISL or Dot1q.
Well, I'm hardcoded for Dot1q on the other side.
So I'm going to hardcode this side for Dot1q
and hopefully that's resolved our issue.
Let's confirm that now by giving
another show interfaces trunk command on switch SW1.
We'll do a show
interfaces trunk command.
It's not come up yet.
Let's give it a few more moments and reissue the command.
And finally it's up.
So we just took a few moments to do the negotiation
after we set the encapsulation mode correctly.
All right, let's make sure it looks the same over on SW2.
We'll do a show
interfaces trunk command.
And yes, it's up on both sides.
And on this side, on SW2,
we're set to dynamic desirable.
On SW1, we're set to dynamic auto,
but both sides are using Dot1q encapsulation.
The status is trunking and the native VLAN is one
on both sides and the allowed VLANs
on both sides are all of our VLANs.
We're not pruning off any VLANs currently.
And that's an example of how
we can go about troubleshooting a Dot1q trunk.