- In the last video I introduced you
to the concept of VLAN trunking.
We took a look at the VLAN tags,
the dot1Q tags in our sniffer trace,
and initially the way we configured our Trunk
was using the command switchport mode trunk.
Changing it from an access mode to a trunking mode.
Now when you use switchport mode trunk,
what you're telling the interface essentially is,
I don't care what you're connected to
on the other end of the cable,
you will do trunking.
So theoretically, if you messed up,
you might accidentally configure that command
on a port leading to a host, like a laptop,
and now you have a problem,
because that switch would be sending frames
down to that laptop.
Some of those frames having tags,
and the laptops don't understand 802.1Q tags,
they don't know what to do with it.
So your Ethernet NIC card on your laptop
would be getting all these sorts of frames
it would have to be throwing away,
because it didn't know what trunking was.
But when you type switchport mode trunk
on the switch interface, it has no choice.
It is doing VLAN trunking.
So another issue or potential problem with that,
from a more practical standpoint,
is we talked earlier, I don't remember how many videos ago,
but I mentioned how interfaces,
I think this was when I first introduced
the concept of switches and bridges
and how each port is its own separate collision domain.
And I mentioned that the way that was possible
was that switches and bridges had memory,
so that if two frames come in
at the same time on one switch,
they're stored in separate sections of memory,
so they don't run into each other.
And that's what I've drawn right here.
So this is one cable,
let's just say this is, I don't know,
FastEthernet0/2 on one side,
and we'll just keep it the same on the other side,
just to make it easy.
And so on Switch-1, this port, FastEthernet0/2,
has some transmit buffer,
in other words, if a frame comes in somewhere else
and it has to go out FastEthernet0/2,
it'll go into the transmit buffer first,
wait for like a picosecond, really really fast,
and then go out on the wire.
And the receive buffer is just the opposite.
If a frame comes in, it goes into the receive buffer,
then gets looked up and switched out.
So that's how these, this is memory, right?
Computer memory.
And that's what this is used for.
Well let's say that on both sides of this link,
I statically configured these two interfaces to be trunks.
So I did config t,
interface fast0/2,
switchport mode trunk.
Okay, it's chugging along, it's just fine,
it's operating as a trunk.
But let's say, and this doesn't happen a lot thank goodness,
but every once in a while, memory gets corrupted.
Maybe there was a huge lightning storm
and there were some power surges,
or you know, whatever happened,
but some memory gets corrupted.
So let's say that the receive buffer on Switch-2
becomes bad, and what I mean by becomes bad is,
either as electrical energy comes in
it can no longer store the ones and zeroes in here,
or as it's trying to store the ones and zeroes
it's corrupting them in some way
and they're getting all jumbled.
So basically, stuff that's coming in off the wire,
going in this direction, is useless,
because it's just dying as it comes right here,
the receive buffer.
Well Switch-1 doesn't know that.
He has no idea that's a problem.
So as far as Switch-1's concerned,
he's happily chugging away, receiving frames,
and then putting them in the transmit buffer,
and then sending them across here,
and then they're just dying on Switch-2,
'cause he's got no place to store them,
or they're being corrupted.
So it might be a better idea if you said, well,
and let's say, to make things even more practical,
as an example,
let's say that there were, for redundancy's sake,
two cables.
You said hey, you know what, if one trunk fails,
I wanna have another trunk pick up the slack.
So I'm gonna configure this as a trunk as well.
Now when you learn about Spanning-Tree,
at the ICND2 level,
you'll learn that Spanning-Tree doesn't like this.
When Spanning-Tree sees two redundant connections
between switches, it says,
hm, there's a problem here.
Because if a broadcast comes in on Switch-1,
it could end up just circling
around these two interfaces forever,
circling and circling and circling,
and so Spanning-Tree says, nope, we're gonna prevent that.
We're basically gonna take down one of these ports.
It doesn't really do that, it's called
putting it in blocking state.
But it says, I'm gonna block this port.
So on this link up here,
I'm not gonna allow any data to go back and forth.
We're just gonna put it on this link down here.
So the idea is,
if this bottom link fails,
if I actually yanked out the cable or shut it down,
then Spanning-Tree would say,
okay I'm now going to unblock this top link.
Now traffic can go across this top link.
So I'm giving you sort of a preview of Spanning-Tree
that you'll learn at the ICND2 level.
But now we have a problem here.
I'm gonna put this up here.
BLOCKED by Spanning-Tree.
So here we have an issue, because Switch-1
doesn't know that the bottom link is bad.
From his perspective, this link is up up,
there's no issues with it,
so he's still taking all the traffic,
and because Spanning-Tree has told him
the bottom link is what you should be using,
that's forwarding, forward your traffic that way,
he's still putting it on that trunk,
and it's dying as it gets to Switch-2.
He has no idea that this trunk is bad.
So what we could do instead
is do what's called dynamic trunking.
With dynamic trunking, these two switches
have to initially exchange some special messages
across this bottom link, and the top link,
if I want the top link to be trunking as well,
special Cisco proprietary messages
that say, I'd like to trunk with you, is that okay?
Now if that message exchange works,
then we can bring up the trunk, but guess what?
As long as that trunk is up,
those special messages are still exchanged.
Hey, you still good?
We still good for trunking?
Yeah yeah, we're alright, we're alright.
So in this particular case, that would fail.
If we used dynamic trunking here,
the special messages that Switch-1 was sending
and saying, hey I'd like to trunk with you, is that okay?
All of a sudden Switch-2
would not be getting those messages anymore.
Why is that?
Well because they would be coming in,
but they'd have to be stored in the receive buffer.
Anything that comes in on FastEthernet0/2
has to be stored in the receive buffer,
but our receive buffer is bad.
So Switch-2 would say, um, we initially agreed on trunking,
and you're supposed to be
sending me these messages periodically,
and I'm not hearing from you.
It's not that Switch-1's not sending them.
Switch-1 is sending them.
But when Switch-2 receives them,
they're getting all messed up.
So from Switch-2's perspective,
he's saying, something's wrong here.
And when that exchange of that messaging protocol fails,
then Switch-2 says, okay I'm no longer gonna trunk with you.
Switch-2 would actually send a message back saying,
trunking failed, no longer trunking,
and this would revert back to an access port.
That's what dynamic trunking can do.
It exchanges these special Cisco proprietary messages
to bring up the trunk,
and then as the trunk is up,
these messages have to periodically still be exchanged
as keep alives, as hellos,
and if something happens where that exchange stops,
now the trunk reverts back to access mode.
Now you might be wondering, "Well wait a second.
"If it reverts back to access mode,
"that means it was carrying all the VLANs,
"all the VLANs that were allowed, that were configured,
"and now it's carrying only one VLAN.
"Which VLAN is it gonna carry?"
That all depends on what you've configured here
in your switchport access vlan command.
So if I had switchport access vlan 4,
while it's operating as a trunk,
this command would do nothing,
'cause it's not an access port.
But if the trunk failed and it had to revert
back to being an access port,
now it would be an access port in vlan 4.
So how do we get this dynamic trunking going on?
It's not the switchport mode trunk,
'cause switchport mode trunk forces it to be a trunk.
And that's what we're gonna talk about right here.
So Cisco has, this proprietary language
that's going back and forth between the switches
is called the Dynamic Trunking Protocol.
I wish I could capture it in a sniffer trace,
but unfortunately the switches available to me in GNS3,
don't support this.
So I can't do that.
But you could google it.
I would recommend, google Cisco DTP sniffer capture,
and you could probably find
a picture of what that looks like.
But the Dynamic Trunking Protocol is that special language
that says, okay, can you trunk with me, are we good?
And then if the trunk comes up,
they still exchange DTP back and forth
to maintain the trunk, to keep it up.
Now clearly, Cisco proprietary.
So if I have a Cisco switch connected to a non-Cisco switch,
you don't have a choice.
Then you'll have to do switchport mode trunk
on the Cisco switch and force it.
Another key thing.
DTP only understood by Cisco switches,
not understood by routers.
Remember in the last lab, or the last video,
when I introduced the concept of VLAN trunking.
Still have the GNS3 up here.
The way I did it was
I had also trunking going from the switch to the router.
This cannot be a dynamic trunk,
because the router does not understand
the Dynamic Trunking Protocol.
So on this interface, on this switch,
I would have to do switchport mode trunk,
even though I'm connecting to a Cisco router.
'Cause the Cisco router doesn't understand DTP.
But from one Cisco switch to another Cisco switch,
I could use DTP.
Now it's optional, you don't have to use it,
but you know on this whiteboard right here,
this is one reason why you might want to.
If you think there's a possibility
where the interface might still be up,
but it might not actually be reachable on the other side.
Something is preventing communication,
bi-directional communication, back and forth,
but the interface is still physically up.
That would be a good use case
where dynamic trunking could detect that.
So when you're configuring trunking you have three options.
So option number one is just switchport mode trunk,
and that's what they're showing you here
as using the keyword of on.
There really is no keyword of on,
it's just switchport mode trunk is on,
so I'll just write that here,
switchport mode trunk.
Okay, now auto and desirable,
these here, to use these,
you have to go into a different mode.
And to use auto or desirable,
you use switchport mode dynamic,
because we're doing dynamic trunking.
And then you get to choose, desirable or auto.
Now almost a guarantee
that whether you take the ICND1, the ICND2, you know,
whatever you take, I can almost promise you
that you're gonna get a question
testing your understanding of,
do you know what the differences are
between dynamic desirable versus dynamic auto?
So let me tell you.
So when you say switchport mode dynamic desirable,
as soon as you hit Enter,
if that interface is up and connected,
it starts sending out DTP messages,
saying hey, I'd like to trunk with you,
can you do that, huh huh huh huh?
You wanna trunk with me?
I would desire that.
That's desirable.
So if you do switchport mode dynamic auto,
he's like sitting back with his hands folded saying,
okay, you could talk to me,
but I'm not gonna talk to you.
In other words, you've gotta initiate.
I'm just gonna sit here and listen,
I'll talk to you if you talk to me.
That's auto, so auto is passive.
It does not initiate the conversation.
So if we think about it, and by the way,
when you do switchport mode trunk,
as we saw in the last video,
please forgive my bad handwriting here,
switchport mode trunk,
DTP is sent.
So even when you do switchport mode trunk,
the side that's configured as switchport mode trunk,
he's not doing anything dynamically,
you've just told him, you will be a trunk,
you have no choice.
But he is sending out DTP as a courtesy,
so that the other side could be desirable if it wants to.
So that being the case, we have to think about,
what combinations of keywords will work to form a trunk?
Which ones won't?
Pretty much every combination of these keywords will work
to bring up a trunk, other than,
if I have auto on one side,
and auto on the other.
If both sides are auto,
neither side is initiating the conversation.
They're both waiting for the other side to talk,
and the other side's not gonna talk.
So in that particular case,
this link will remain as an access port
in whatever VLAN it's configured to be in.
It will not do trunking.
Somebody has to initiate the conversation.
So that could be a desirable,
or that could be switchport mode trunk,
but one side has to initiate.
In a lot of Cisco documents, they actually recommend
that you set both sides to desirable.
That's what they typically suggest,
is you do switchport mode dynamic desirable on both sides.
But I'm just showing you here
there's a lot of other combinations that could work.
I could have switchport remote trunk, mode auto,
switchport mode dynamic desirable, dynamic auto,
dynamic desirable, dynamic desirable,
you know as long as someone is initiating the exchange,
the other dynamic side can pick it up and talk.
And we verify it, oh, and switchport nonegotiate.
Really the only time I can think of where this
might be something you wanna do is,
let's say that you have an interface on your switch
connected to a device that does not understand DTP,
and you just say to yourself, well,
there's really no point in putting DTP on that wire.
I mean it takes up tiny little bit of bandwidth,
I mean it doesn't go out that frequently,
but if you say to yourself, you know what?
I don't even want it going out at all, there's no point.
Well you could say switchport mode trunk,
force it to trunk,
and then on top of that, say switchport nonegotiate.
That means don't send any DTP at all,
just turn off DTP processing.
And verifying it is the exact same way
that you verify it with the other show commands
that we've looked at.
So let's just do a quick lab on that,
so you can see what it looks like.
So for this, I am going to log into INE's Racks.
And because I've used our racks so frequently,
I know what the topology looks like.
But I'll just draw it here real quickly for you.
I know that Switch-1 is connected to Switch-2,
via FastEthernet0/10 on both sides.
So that's what I'll be configuring.
Now one other thing you should be aware of.
You might be wondering, well when it comes to modes,
so so far we've talked about switchport mode access,
switchport mode trunk,
and switchport mode dynamic,
with either auto or desirable as the keywords.
You might be wondering, what's the default mode?
When I just wipe out the configuration
and start from scratch,
or I take a brand new switch and I turn it on,
which of those modes is it by default?
Pretty much all Cisco switches, by default,
are switchport mode dynamic.
You might be saying, "Well wait a second,
"you can't be done yet,
"it's either dynamic auto or dynamic desirable.
"Which one is it?"
That depends on the model of switch.
Some switches are switchport mode dynamic auto by default.
Most of them are.
But some switches are switchport mode dynamic desirable,
by default.
And that can sometimes throw people for a loop,
because they say hey,
I just connected these switches back to back with cables
and these trunks just came up.
I didn't mean for that to happen, it just happened.
Well that's because at least one of them
was dynamic desirable by default,
and as soon as you connected the cable,
it starts sending DTP, without you doing anything.
Let's see what these ones are.
I know these are Catalyst 3560 switches.
So one way you can tell is,
first of all, let me take a look at the interface
and see if it has any existing configuration on it,
no it doesn't.
Okay so, this interface doesn't have any configuration.
So I can type show interface fast0/10 switchport.
And there we go, dynamic auto, it's dynamic auto.
So that's why it will not,
form a trunk until I tell it to.
Okay, so I'll go into int fast 0/10.
And I'll say, let's just shut it down first.
I typically recommend that if you're changing
the physical layer or data link layer
characteristics of an interface,
it's a good idea to shut it down first,
make your layer 1 or layer 2 changes,
and then do a no shutdown afterwards.
Sometimes when you try to change those types of things
while the interface is up, weird things can happen.
So let's just do switchport,
switchport mode dynamic desirable.
While we're at it, switchport trunk encapsulation dot1q.
Switchport.
No shutdown.
Now before I do a no shutdown,
I don't know, 'cause I haven't looked yet,
what the state is of this interface.
If this interface is ready to go,
if it is not administratively disabled, if it's ready to go,
and if it is in the default auto state,
the default state of dynamic auto,
the moment I do no shut on here,
I just configured him to be dynamic desirable.
So the moment I bring him up,
he should start sending DTP, the Dynamic Trunking Protocol.
And if this other side comes up, and he's auto,
the trunk should come up.
I shouldn't have to do anything on Switch-2.
So let's just see what happens here.
Interface changed state to down.
Okay so that's telling me, remember what we said?
Remember what I said when I said show IP interface brief.
And it says our troubleshooting step,
if I have an interface that I know
is connected to something and it's down down,
what did I say?
I said well, maybe there's no cable connected at all.
Maybe there is a cable, but the other end of that cable
is not connected to anything.
Or the other end of that cable is connected to something,
but the other side is administratively down.
Let's take a look.
Show run interface FastEthernet0/10.
See?
It is shutdown.
Okay, changed state to up, that's good.
And if this becomes a trunk,
I should get some messaging about that, I would think.
Changed state to up, so this is the data link layer,
the line protocol indicates layer 2.
This here indicates the physical layer.
So far I haven't gotten any messaging
about it being a trunk.
What is the command I can type
to see if I have any VLAN trunks on this switch?
That command was show interfaces trunk.
And it is.
So I didn't get any Cis log message,
I didn't see any messages about it,
but here it is.
It says it's in auto mode,
n means it dynamically negotiated,
that's what the n is for, it negotiated 802.1q.
And here it says native VLAN is 1.
So this says it's in dynamic auto,
let's take a look at Switch-1,
who I configured as dynamic desirable.
Show interfaces trunk.
See?
His mode says desirable.
And that concludes this section
on Cisco's Dynamic Trunking Protocol.