Alright folks, now we're going to dive into our discussion on trunks.
Now the great news here is that even though there's two different trunking options that exist in a multitude of iOS versions,
we only need to know one nowadays because Cisco has bowed down and said that their trunking or proprietary trunking encapsulation
is not as good as 802.1Q, the industry standard.
So I remember a time when I used to have to learn both, be tested on both, and all that stuff, and troubleshoot both.
Nowadays, you're really only worried about 802.1Q.
So, why do we need trunks? Well, let's just talk about what happens when we don't have trunks.
So what do we have right now? We have VLAN 10 here.
We have VLAN 20 here.
Oh, and also VLAN 200.
So by default, folks, which VLAN is that Lincoln?
By default, which VLAN is that Lincoln?
VLAN 1, 2, 3, 4, 5, 6, what's the default? VLAN 1, exactly.
So this is in VLAN 1. This is in VLAN 1. This is in VLAN 1. This is in VLAN 1.
They're all in VLAN 1. And we can verify that right here.
There's 45, 46, 47, 48. They're all in VLAN 1.
So, can VLAN 10 traffic go out this interface?
No, because what is our rule? Traffic from one VLAN can only go out ports that are in the exact same VLAN.
So that's not going to work. Same thing with VLAN 20 and 200 here.
So what we could do is we could say you're in VLAN 10, you're in VLAN 20, you're in VLAN 200.
But what's the problem with that?
The problem with that is that for every single VLAN we have, we are going to have to have a link.
And that's just silly. That's not going to work. It's not going to scale well. It's going to be horrible.
So that's why we have trunks.
When we use a trunk, I can now pass traffic for multiple VLANs to cross a single physical link.
So this trunk will allow me to pass traffic for VLAN 10, 20, 200, as well as whatever VLAN we have.
We have VLAN 50 as well. So 10, 20, 200, VLAN 50. VLAN 50 is down here, remember?
Same thing, 10, 20. So these are trunks that can pass traffic for all VLANs that we have.
So that's why we want to use trunks.
That's when it comes to the native VLAN. We're going to get to that. We're going to get to that.
So what is a trunk? A trunk is a single physical link that can send and receive traffic for multiple VLANs.
A trunk is a single physical link that normally would only be allowed to pass traffic for one VLAN,
one data VLAN, one voice VLAN, and now I can pass traffic for all VLANs on it.
So we're going to be focused on what? Our switch-to-switch trunk links here in this discussion.
But we could do switch-to-router trunk links, and we'll see that later today.
We're going to see that later today during our inter-VLAN routing discussion.
In this scenario, what do we have? We have a single switch port, and we're going to have VLANs 254 here and VLANs 255.
So how do I pass traffic for both those VLANs across this single physical link?
Well, I'm going to have to put a trunk here, which means that my router is also going to have to support trunking as well.
All right, so we'll show you how to do that later today, but there's an example of switch-to-router.
What about PC or server-to-switch? Well, let's say here we had a server, and this server had VMs,
and let's say this VM was for VLAN 10, and this VM here was for VLAN 20, and this VM here was for VLAN 200.
Well, then how would I pass traffic for all those VLANs across a single physical link?
We would need a trunk link there, so this would have to be a NIC, network interface card, that supports 802.1Q trunking, as an example.
Okay, what about an access point to a switch? So let's say, for example, we have an AP here.
Every single SSID you have, folks, is a different VLAN. So if you have a guest SSID, that's one VLAN, one subnet, one broadcast domain.
If you have an enterprise SSID, that's one VLAN, one subnet, one broadcast domain, and so on and so forth.
So for every SSID you have, you are going to have essentially a different what? Subnet VLAN broadcast domain.
So therefore, we would have to have a trunk here so we can pass traffic for those different subnet-sized, VLAN-sized broadcast domains.
Now, how many of you – now, that is if they're standalone access points.
If you're using lightweight access points, then you'd have cap-lap tunnels, and the configuration changes in that case.
What about the wireless LAN controller, for example? So let's add a wireless LAN controller down here.
Well, in those lightweight access point scenarios, you'd have your cap-lap tunnel from your access point to your wireless LAN controller,
and then as the traffic leaves, that could be traffic for different VLANs.
So if it's traffic for different VLANs, there's going to have to be a trunk in that particular case.
So all different ways that we can create trunks.
So what are we going to have to do? We're going to have to configure our port as a trunk, configure this port as a trunk,
and make sure all the parameters that are necessary match appropriately.
And then in the end, we'll have our trunk, and we'll be able to pass traffic for multiple VLANs across it.
And what's going to happen is that a tag is going to be added to our frames.
A tag is going to be added to our frames to identify the VLAN that the frame belongs to.
So let's take a look at this example here. We have our PC frame right now.
So I have a frame coming from this PC. It's going to arrive at ASW1.
Okay, pop quiz, folks. How does the switch know which VLAN that frame belongs to?
We configured it. Exactly. We configured it. Switch port, access, VLAN 10.
So it knows it's what? VLAN 10. It knows that. It's a configuration we put on it.
There's nothing in there identifying anything about the VLAN that belongs to that VLAN.
Even if there was, even if there was something in here that said, oh, VLAN 30,
because our port is configured as VLAN 10, we would also have a configuration on there
that would override that.
So let's take a look at this example.
So let's say I have a VLAN 10. I have a VLAN 10.
We would also have a configuration on there that would override that.
So that way there, we don't allow anybody to fraudulently use VLAN numbers they're not supposed to.
So if all of a sudden we did receive a tag frame from a PC and we shouldn't be,
we'll change it to VLAN 10.
And that's a discussion for another day.
But just to let you know that absolutely, if that is a problem,
you're going to want to make sure you can stop that from happening.
Now, what happens now if the switch just sends it over to this switch unmodified?
Okay, so remember, this is a trunk link now.
What if we just send this frame as is to DSW-1?
When it arrives at DSW-1, how does DSW-1 know which VLAN the frame belongs to?
It doesn't. Okay, let's be very clear about that.
It does not know. Why not? Because there's nothing here.
And we have this concept called the native VLAN.
And by default, the native VLAN is VLAN 1, okay?
By default, the native VLAN is VLAN 1,
which is also the same number for our default Ethernet VLAN, remember?
But the native VLAN for trunks basically says if there's no tag, you belong to that VLAN.
It's essentially what it means. We'll talk more about that later.
So basically, DSW-1 says you're in VLAN 1. Is that correct?
No, it's not, is it? It's not correct at all in this case.
So what has to happen is this switch here needs to modify that frame.
It needs to modify the frame.
So what is it going to do? It's going to open it up.
It's going to open it up.
And then what's it going to put in there? An 802.1Q tag.
And then it's going to label it, 802.1Q tag.
And if we have to put any class of service, quality of service values in there, we will.
In this case, this is date user traffic, probably COS value of zero.
And then our VLAN ID is what?
Ten.
Exactly. Ten.
So now, as the traffic leaves, it looks like this, the frame.
So when it arrives at DSW-1, DSW-1 is going to say,
So when it arrives at DSW-1, DSW-1 now knows it belongs to VLAN 10.
That's why we are tagging to tell the other switches which VLAN that traffic belongs to.
If it wasn't for this tagging we were doing, then this switch would not know which VLAN it belongs to.
And therefore, it would go from VLAN 10 over to VLAN 1.
And yeah, exactly as the chat says, that would cause leakage.
Leaking from one VLAN to another VLAN, which we don't want.
That's why tagging is so important.
And it's so important that we do it right.
So the same thing would happen in reverse when traffic has to go the other way.
So let's go back to here.
Let's type in right now on ASW-1.
Show interfaces trunk.
And we'll see here that there are no trunks at all configured.
In our case, if I type in do show VLAN brief,
in our case, if I type in do show VLAN brief,
we're going to see in our output here 45, 46, 47, 48.
Those four are currently part of the default Ethernet VLAN of VLAN 1.
Therefore, they only support traffic for VLAN 1.
VLAN 1.
Bigger terminal.
I'm going to type in right now just quickly to show you.
Interface gigabit 1, size 0, size 45.
I'm going to type in switch port mode trunk.
I just turned it into a trunk port.
That easy.
So now I'm a trunk port.
If I type in show VLAN brief,
what we're going to see is that it's no longer listed here.
You see it's gone.
It's gone.
Trunk ports do not show up in the output of show VLAN.
Nope.
Why?
Because on Cisco devices, if you're a trunk port,
you pass traffic for all VLANs.
That's what you do.
That's your job.
You don't belong to any single VLAN on Cisco devices.
Now, other switches from other vendors, it is possible you would.
You would actually have your trunk ports in a specific VLAN.
And we don't do that on Cisco devices.
So on Cisco devices, if you don't see the port here,
it's either one, because it's a trunk,
or two, because it belongs to a VLAN that doesn't exist,
as we saw in our VLAN discussion.
Right now, if we type in show interface gigabit one size zero size 45,
not the output I'm looking for.
Let's type in switch port.
There we go.
That's the output I'm looking for.
You're going to see here that we are a trunk port.
We are operating in a trunk port.
We are operating as a trunk port.
We are operating using 802.1Q industry standard trunking encapsulation.
802.1Q.
Notice that it says my access mode VLAN is VLAN one.
That simply means if I am no longer a trunk port,
then I will be in VLAN one.
That's what that means.
If you ever see a VLAN number listed here on a certification exam,
it's used more as a fallback mechanism.
If I am no longer a trunk, then I will be put in a certain VLAN.
The key is always to look at the configuration.
If the configuration shows that you are a trunk,
then this number doesn't matter.
If it shows that you are access ACCESS,
then this number matters.
Same thing with voice.
Voice doesn't matter now because I am a trunk.
But if I wasn't a trunk,
then whatever voice VLAN was listed there would be.
It'd be none in this case, which is good.
It's what I would want.
John, we're going to get to that later.
We're going to get to that later.
Native VLANs cause a lot of confusion.
You'll see here it says native VLAN is one.
Native VLAN is one.
What does that mean?
We're going to get to that.
It is a very confusing thing of 802.1Q.
It is actually very simple.
It is actually very simple in the industry standard documentation.
But the way Cisco uses it, it's complicated.
It doesn't make sense.
It really doesn't.
But we're going to get to it.
We're going to get to that.
What about when you are using VLAN allowed
to limit VLANs that are not native?
Yeah, we're going to show you how to do that as well.
We're going to absolutely show you how to do that.
Okay.
So none of these, this doesn't matter when we are trunks.
What matters here now is this.
This matters.
That matters.
We're going to come to that shortly.
What else matters?
This matters now.
This matters here.
This matters here with VTP.
This matters.
Yeah, okay.
And then private VLAN information is here,
which is beyond the scope of the course and certification exam.
So it's important that you can read,
so far, what I've shown you
when we were talking about our access ports,
and now also what I'm going to show you
when we talk about our trunk ports.
Now, before we start digging this further,
I've only configured one side, one device.
It shows I'm trunking.
But what I want to do for a moment
is I want to erase this configuration,
and what we have to do is we have to talk about
the multitude of different ways
that we can configure an interface as a trunk
on a Cisco device.
Now, what I showed you here
is the way you really want to do it in the real world.
That is the best way to do it.
It means you are a trunk.
There's no if, ands, or buts about it.
You are a trunk.
You are in 100% control here.
But what I want to point out to you
is there's this thing called DTP.
Dynamic Trunking Protocol.
It's not a WWE move.
That was the DDT by Jake the Snake Roberts,
not DTP here.
Dynamic Trunking Protocol, DTP.
So what happens is that we have
switch port mode trunk.
This here says,
okay, there's no negotiation going on.
You are a trunk, plain and simple.
But if we type in switch port right now
and we type in mode,
I want you to see that we have the opportunity
to set it to access.
More on that later.
We saw that in our VLAN discussion.
Trunk, which I just showed you right here.
But then there's also this dynamic option.
So if I type in dynamic,
you'll see that there's different options,
auto as well as desirable.
We have to talk about these.
Even though you really wouldn't need
to use them in the real world.
Because you could just use
switch port mode trunk on your interfaces
because you want them to be trunks.
You don't need dynamic negotiation.
So why in the world does this exist?
Because way back in the day,
like I'm talking way back folks,
years and years and years and years ago,
like over 20 years ago,
maybe 30 years ago now,
there was this like groundbreaking
technological evolution that happened.
Does anybody know what that
groundbreaking technological evolution was?
Plug and play.
That's what it was.
If your devices weren't plug and play,
people didn't want them.
That was true for PCs,
true for many different things,
but a lot of networking equipment as well.
So Cisco took it upon themselves and said,
hey, you know what, how can we do this?
How can we help you out?
So they created a protocol called
dynamic trunking protocol, DTP.
And we just take a moment to go back
to this beautiful diagram we have here
and clean it up a bit.
This was at a time, folks, no joke,
if you weren't aware of this,
there was a time in our lives
when all of this was layer two.
How many of you are old enough to know
of a time when all of this was layer two
and layer three was out here?
And you might have, for example,
you might have a device somewhere
like a router that could route you
or do inter VLAN routing
for your different subnets.
Anybody old enough to know about this?
Yeah.
Why? Because at the time,
switches were faster than routers.
Switches were lightning faster than routers.
And switching was superior to routing.
So we only use routing
when it was absolutely necessary.
What did that mean?
It means that every resource you wanted to access
was in your subnet, was in your VLAN,
was in your broadcast domain.
So if I was sitting here on my PC,
my server over here, my DHCP server
was actually in the same subnet,
VLAN broadcast domain as me.
VLAN 10, VLAN 10.
No joke.
And nobody's old enough to know about this?
Yeah.
That's why when you think about a protocol like DHCP
and you're like, I don't understand
why the discover message is broadcasted
when my DHCP servers are always centralized.
It makes no sense.
Well, it was designed in an environment like this
when it made sense.
So I send out my traffic
and it's layer two switched
all the way to the server.
So yes, spanning tree protocol
running in this entire environment, absolutely.
Yeah, ugly.
Ugly.
But what did that mean?
This had to be a trunk, this had to be a trunk,
this had to be a trunk, this had to be a trunk,
this, this, this.
We don't do this today anymore, right?
We minimize the number of trunks we have.
We want like minimal trunks in our environment.
Minimal spanning tree protocol.
Minimal layer two,
lots and lots and lots of layer three routing today.
Why?
Because routing is far superior to layer two nowadays.
But yeah,
and then you can have somebody in VLAN 20 right here.
And there's their VLAN 20 server over here.
So trunks,
passing traffic from multiple VLANs.
So DTP was invented
so as soon as you plug two switches together,
a trunk is automatically formed,
meaning you don't have to do anything.
That's right.
You plug a switch into another switch,
you got a trunk.
That's it, that's why it was invented.
Plug and play.
As a network admin, right,
you got a cable, you got a switch, plug it in.
You got another switch, plug it in.
Guess what, trunk's already configured, don't worry about it.
Now, if you needed to do filtering and other things
and all that stuff,
then you'd still have to go and do that yourself after the fact.
But the actual trunk was automatically formed for you.
So Dynamic Desirable was typically
what was configured on both sides by default
right off of the manufacturing lot of Cisco.
Dynamic Desirable.
What does it say?
Send and wait for DTP messages to arrive
on the link
and negotiate the format.
So you were always, as soon as your link came up,
you were sending DTP messages, sending DTP messages.
Why?
Trying to form a trunk with the other side automatically,
that's what you were doing.
And then auto
is used if you don't want to send,
but you still want to form a trunk.
So for example, auto says wait for DTP messages to arrive
to form a trunk with the other side.
So what does that mean?
It means if both sides are auto,
you're not going to be able to form a trunk.
And that is what the default is today.
That is what the default is today.
So if we look at ASW1 right now,
we type in do show run pipe,
no, no, no, no,
do show interface gigabit one size zero size 45 switch port.
That's what I want.
You'll see that it says dynamic auto right here.
Let's go over to DSW1.
And on DSW1,
we'll change it to we are 21.
Okay, dynamic auto.
So auto auto on both sides means we're both waiting today.
So, but back in the day, they were both dynamic desirable.
That's right.
Both dynamic desirable.
I still have switches here in one of my stacks
that defaults to dynamic desirable.
And as soon as you plug in one switch that's dynamic desirable
into any other switch that supports DTP,
it automatically forms a trunk no matter what.
So auto auto doesn't work.
And so by default, most Cisco switches today are auto.
Because even Cisco says you don't really want to use this
unless you absolutely want to use it.
Why?
Because why rely on a dynamic protocol
to form a trunk for you
when you can manually do it yourself?
See, it made sense back in the day
when you had thousands of trunks.
But today, you don't have as many trunks.
You have a lot less.
And you can manually control those today
as opposed to allowing DTP just to do it for you.
So auto auto doesn't form a trunk.
I want you to know that because on the exam,
if you ever see a scenario
where they're showing you auto on one side
and the other side's also auto,
and they're asking you why is a trunk not forming
or solve the problem as to why the trunk's not forming,
there's your problem.
They're both auto, first and foremost.
So you have to have the right settings on both sides.
So desirable auto will work.
Just change one side to desirable.
The other side stays auto.
It's going to work.
So right now, let's type in switch port mode dynamic desirable.
And we'll see here after our interface is flap
that typing in the command do show interface gigabit
one size zero size 45 switch port.
I am now dynamic desirable.
I am now a trunk.
I am using 802.1Q.
We are using DTP.
Our native VLAN is VLAN number one.
We go over to DSW1,
look at the output of that command now,
and you'll see that I'm still dynamic auto,
but now I am a trunk.
Okay, what was I before?
I was dynamic auto, but I was an access port.
And if you ever see access there, what did I say?
I'm an access port.
I'm part of VLAN one, right?
Whenever you see access,
then this matters and this matters.
But anytime you see trunk, they don't matter anymore.
So now that it says trunk,
this doesn't matter.
This doesn't matter, right?
What matters?
The fact that I negotiated 802.1Q.
That's right.
I negotiated it.
Why?
Because it supports our trunking encapsulation protocol.
Cisco's proprietary trunking encapsulation protocol of ISL.
It does support it.
We'll talk about that momentarily.
When I show you a config here,
this switch won't allow me to do the configs
without actually manually setting my encapsulation as well.
But because the other device was doing dynamic desirable,
everything could be negotiated.
Negotiated trunking is on.
Native VLANs one is an example.
So let's just type in here now,
do show interface trunk.
And you'll see in this output
that gig one size zero size 21 mode auto
negotiated 802.1Q trunking encapsulation
and the native VLAN is one.
We'll go over to ASW1.
We'll take a look at now show interface trunk.
And it says here that we are mode desirable.
802.1Q is what was used.
Notice it doesn't say negotiated
because this device only supports 802.1Q.
It doesn't support ISL.
It only supports native VLAN of one.
So auto auto will not form a trunk,
but desirable auto will definitely form a trunk.
Therefore, desirable desirable will also form a trunk as well.
So no, nothing crazy there.
Okay, trunk desirable will still work.
Absolutely.
Now why is trunk desirable still going to work?
Because what I want you to realize
is that even though trunk forces the interface
in the trunk mode,
no matter what the other side is configured like,
it still supports DTP,
meaning DTP is not shut off.
So if we go over to, for example, ASW1 now,
and we type in switch port mode trunk instead,
and we look at our output of show interfaces trunk,
you'll see that says mode on.
Mode on means what?
Mode on means we typed in switch port mode trunk.
That's what it means.
If we look at the output of show interface gig
one size zero size 45 switch port,
you'll see the administrator mode is trunk,
operational trunk.
We are using 802.1Q.
And notice that DTP is still on.
That's why trunk works with desirable.
DTP is still on.
So I'm still sending and receiving DTP messages,
even though we typed in switch port mode trunk.
It's the default behavior.
So therefore trunk works with desirable.
Trunk works with auto.
Trunk works with trunk.
No surprise there.
But trunk will not work with access.
Auto will not work with access.
Desirable will not work with access.
It's important that you know
all those combinations for the exam.
Because you never know when you'll receive output,
and you're trying to figure out
why is the trunk not forming.
So it could be this output here.
So if you're looking at this output,
you're looking at the administrative mode.
Is the administrative mode listed on this device?
Inappropriate.
Administrative mode.
That works with this.
So does trunk,
administrative mode,
and auto administrative mode work?
Yes they do. Absolutely.
That's if and only if DTP is actually on.
And in this case, it is.
So in modern day networks,
it is best practice to disable DTP negotiation
and set everything manually exactly.
And that's what I'm going to show you to do here momentarily.
That's the config I'm going to provide to you
for the real world.
So on the exam,
you might have to do that config,
or if they tell you to use DTP
or they tell you to use dynamic desirable on one side,
then you just got to do it.
Do what they tell you to do.
But you've seen now how to configure DTP.
Or you configure desirable, I should say.
And auto is the default.
And I'll show you how to configure trunk momentarily.
So trunk, trunk,
definitely a good way to go
and not worry about dynamic desirable
or auto in the real world.
And then make those access ports down on ASW1.
Why?
Because as an access port,
you're disabling DTP on the interface
as an access port.
So down here.
Do we need DTP running there?
No, we don't.
Because there is no device
that is out those interfaces
that we're trying to form a trunk with.
Now, if there was, different story.
But most of the time,
no, we're not trying to form a trunk with our Cisco phones.
We're not trying to form a trunk with our PCs.
So if it's going down to a phone,
a PC, a printer, et cetera, et cetera, et cetera,
and we don't need a trunk,
then you might as well set the port
to switch port mode access.
Never, ever, ever, ever, ever
allow this port to become a trunk.
No matter what.
Even if somebody's forcing us to.
We're getting bombarded with DTP messages
or we're getting bombarded with some message.
No, no.
Unless an administrator comes in and types in
no switch port mode access
or switch port mode trunk
or switch port mode desirable,
that's the only time we're going to get changed.
We will never form a trunk at all
if it's switch port mode access.
Therefore, we would belong
in our voice VLAN in that particular case.
So let's just go ahead and do that
because we saw that as part of our config earlier.
So what I'll do is I'll type in interface range
gigabit ethernet one size zero slash,
oops,
one, two, three,
and then we'll type in switch port mode access.
There you go.
But before I do that, you know what?
I want to change this again.
I want to go back because I just want to show you this first.
Do show interface gigabit ethernet
one size zero slash one.
So I erased it.
And let's type in switch port.
So what you're going to see here
is that it says we're dynamic auto.
See, that's the problem.
That's what I'm trying to change.
By default, these are dynamic auto.
So if I do not,
and then if a DTP message comes in,
then I become a trunk port.
So what I want to do is I want to make sure
I never, ever, ever become a trunk
and I shut off DTP all at the exact same time.
So let's type that in.
Switch port mode access.
And now when we look at our VLAN,
our output, you'll see it says
my administrative mode is static access.
So anytime you see administrative mode static access,
it means this command was typed in.
Therefore, since the administrative mode is static access,
the operational mode is static access,
which means this doesn't matter.
This doesn't matter.
Look, DTP is off on the access port now.
Therefore, this is the VLAN I belong to for access.
And this is the VLAN I belong to for voice.
Perfect config for the exam.
Do, show, run, interface, gigabit, one size zero slash one.
There you go.
All right.
Port fast is there, but
that is something we'll talk about later.
So there you go.
So far, perfect three commands
that I want you to memorize for the exam.
The only thing that would be different
is the VLAN numbers for you.
All right.
Let's go back to our trunk ports now.
Let's do interface range.
Gigabit Ethernet, one size zero slash 45, 46, 47, 48.
So we're going to configure all four of these right now.
All four of these.
But before we do that,
I want to talk about shutting off DTP.
No DTP.
Basically, I want to disable this,
and I want to disable this.
That's what I want to do.
But you don't have to do this.
But if you wanted to,
what you would do is you would do trunk with no negotiation.
Trunk with no negotiation means
that you want to shut off DTP.
And we'd have to do that on both sides
because once you do that to one side,
you can't have the other side as dynamic desirable,
and you can't have the other side as dynamic auto
because once you do trunk no negotiate,
the other side has to be trunk or trunk no negotiate.
But it can't be dynamic desirable or dynamic auto anymore.
So what we're going to do here
is we're going to configure these as switch port mode trunk.
Now that converts into the trunk ports.
So I type in do show interface gigabit one size zero slash 45.
Switch port.
What you're going to see is that
we are administratively mode trunk.
Operationally, we're trunk.
But look at this.
We are
still using DTP.
So how do we shut off DTP?
You type in switch port,
no negotiate.
Now that shuts off DTP.
So if we look here,
you'll see that DTP is now off.
So I want to be super careful with this.
Why? Because
if you look at this here,
and I asked you right now,
how was DTP disabled?
You can't just say
that you use this command.
Why is that?
Scroll up.
Remember what we did moments ago?
Why was DTP disabled?
Because you typed in switch port mode access.
How do I know that?
Because it says administrative mode static access.
Pay attention to the details.
How was DTP disabled?
Well, because administrative mode is static access,
that means it's because we typed in switch port mode access.
Okay, let's get back to the bottom.
How was DTP disabled?
Well, because the administrative mode is trunk,
it must mean we typed in switch port,
no negotiate.
There you go.
Wow.
Not two ways.
Hang on here.
Hang on.
Not two ways.
Think about it.
One's a trunk port.
One's an access port.
How do you shut off DTP on an access port?
Type in switch port mode access.
How do you shut off DTP on an access port?
Type in switch port mode access.
How do you shut off DTP on an access port?
Type in switch port mode access.
How do you type shut off DTP on a trunk port?
Switch port no negotiate.
Right?
It's just two different types of interfaces.
Two different commands accomplish the same thing.
Yeah, so yeah, okay.
There's two ways then.
But it's about the interface type that is more important.
Is it an access port or a trunk port?
That's going to make a difference.
Yeah.
Right, so now you can see here we've got our four ports.
There's trunk ports.
And because it says on,
it was switch port mode trunk that we typed in.
802.1Q is the only encapsulation method that's supported on this device.
And notice by default we're allowing all VLANs automatically.
Talk about that more later.
All right, let's go to DSW-1 though.
Right, because on DSW-1 right now,
what we're going to do is we're going to type in
interface range gigabit Ethernet.
We want all of these interfaces here.
Every single one of them.
So that is 17, 18, 19, 20, 21, 22, 23, 24.
So gigabit Ethernet 1 slash 0 slash 17 through 24.
Now we're going to type in.
I'm going to do it in an order that many people say,
well, why don't we do it this way?
Why don't we shut off DTP first?
That way their negotiation is gone.
So let's do that.
Switch port, no negotiate.
Do not do that.
Why?
You cannot shut off DTP if your interfaces are currently what?
Auto or desirable.
And we are currently running what?
Auto on those interfaces.
You can't shut off DTP if your interfaces are running auto or desirable.
That's why this error message has shown its face.
So order of operations matter here.
So let's type in switch port mode trunk.
Look, I can't even do that on this device.
What?
And the reason why is because this device supports two types of encapsulation.
This device only supported 802.1Q.
This device supports 802.1Q and ISL, as I mentioned before.
So if we type in switch port trunk encapsulation, you'll see .1Q and ISL.
So ISL is Cisco's proprietary trunking encapsulation protocol.
They invented that before 802.1Q existed.
And so back before VLANs and trunking became a standard,
many different vendors did it on their own in different ways.
Cisco created VLANs 1 through 1005, as we talked about before,
and they created a trunking encapsulation protocol called ISL.
ISL requires 30 bytes in order to encapsulate the data
for transportation across the link,
where something like 802.1Q requires how many bytes?
Well, if we come back to this page here, two bytes for here,
two bytes for the rest, four bytes in total.
Four bytes in total.
So 802.1Q only requires four bytes, whereas ISL required 30.
Therefore, ISL very, very bloated,
and Cisco was like, no, we don't even need to use it.
So if your device supports ISL, we're probably not going to be using it.
You're going to be using 802.1Q.
Will ISL show up in the exam? It shouldn't.
The only time I could see it showing up
is if they're trying to test you on trunking encapsulation,
because the encapsulation has to match on both sides,
meaning that if this side is using 802.1Q,
then this side also has to be using 802.1Q.
If this side was using ISL, then it wouldn't work.
Then it wouldn't work,
because you're speaking one language, 802.1Q here,
and you're speaking ISL over here.
It's not going to work.
So let's try that for a second.
So let's do switch port trunk encapsulation ISL,
switch port mode trunk, switch port no negotiate.
So the thing is, is that because this side is set to 802.1Q
and this side only, and then the other, yeah,
they're all set right now to 802.1Q.
And that's the only thing they support.
We're going to see that when we type in
do show interfaces trunk,
it shows here that 21 and 22 are listed, doesn't it?
If we go over to the other side,
45, 46 are listed.
The thing is, is that even though they're listed,
it doesn't mean they're working.
If somebody tried to communicate right now
and traffic was flowing,
traffic would not get across this link,
because this side is encapsulating with 802.1Q,
and the other side is using ISL,
it has no idea how to decapsulate it.
It doesn't understand it.
It's like one side speaking one language,
the other side speaking another language.
You need a translator,
but you can't translate 802.1Q to ISL.
So if ISL shows up in the exam,
it's because they're trying to test you on this concept,
where encapsulation has to match
on both ends of the link
when it's all said and done.
And if it doesn't match it,
then it's not going to work.
So let's go back and change that
to switch port trunk encapsulation,
802.1Q, or no, it's .1Q,
that's all it's listed as, .1Q.
Yeah, ISL only supports VLANs up to 1005,
and that's why those restrictions are in place,
as well with our normal VLANs
versus our expanded range VLANs.
It's all those restrictions we have,
everything we talked about with our VLANs,
it's all because of VTP,
a Cisco proprietary protocol,
ISL, Cisco proprietary protocol
that were invented before,
we could support 4096 VLANs.
So now if I type in do show interface trunk,
there, so for example,
you may see on the exam output like this
for one device,
or you might have to type in show interface trunk,
an output like this for another device,
or you have to type in show interface trunk,
and your whole point is to answer
a multiple choice question that says,
why is traffic, or why can't PC1
communicate with so-and-so?
Well, it could be something like this,
the trunking encapsulation doesn't match
between our switches.
Look for the multiple choice question,
if that's what it was, there it is, answer C.
Change the trunking encapsulation
on DSW1 to 802.1Q.
But you'd have to be able to verify,
are we actually using 802.1Q?
Oh yeah, look, this one's 802.1Q,
this one's ISL, okay,
we got a trunking encapsulation mismatch.
Therefore, traffic wouldn't flow,
because it couldn't be encapsulated
and decapsulated properly.
All right, now let's go ahead
and do the rest of our configurations
on the other devices.
So DSW1, configure terminal,
interface, gigabit ethernet,
or interface range.
Oops.
All right, and lastly, ASW2.
The question earlier was,
hey Raymond, is it best practice
to configure your interface
as a trunk and forget about DTP
and shut it off?
Yes, and that's what we're doing.
So switch port mode trunk,
switch port and then negotiate.
Right now on this device also,
let's not forget that this device,
we have some access ports.
So if we come back here,
let's not forget that we've got
access ports here.
So what we're going to do,
we're going to type in
interface gigabit 1.0.1.
Oh, wait a second,
we never even created our VLANs here, did we?
I need my VLANs.
So we need VLANs 10,
we need VLANs 20,
we need VLANs 50,
we need VLANs 200.
So we've got all of those configured now.
And now we can type in
interface gigabit 1.0.1.
And that is the interface in VLAN 20.
So switch port mode access,
switch port access VLAN 20,
switch port voice VLAN 21.
Switch port voice VLAN 200.
Interface range,
gigabit ethernet 1.0.2.3.
Those are the interfaces in VLAN 50.
So we'll type in switch port mode access,
switch port access VLAN 50,
and switch port voice VLAN 200.
Now, if we go over to DSW1 as an example,
I want to take a look at the output of our chunks right now,
because I want you to see here
that only VLAN 1 is showing up.
You see that?
Why is only VLAN 1 showing up?
And the reason why is because
we never configured our VLANs on our device.
So if we type in do show VLAN brief,
again, you'll see no VLANs.
So if the VLANs aren't there,
then you can't pass traffic for those VLANs.
So always remember that when you're
configuring, verifying, and troubleshooting VLANs,
double check, is the VLAN in the database?
If the VLAN is not in the database,
that's your number one reason why things aren't working.
The VLANs have to be there.
If the VLAN is not there,
your switch can't pass traffic for that VLAN,
no matter what else is configured.
We've got all our chunks configured and everything else,
but you will only pass traffic across a chunk
if it's what?
In your VLAN database.
You will only pass traffic in and out of port
that belongs to a VLAN if that VLAN exists.
So the VLAN has to exist.
And you'll see that once I've done this,
the VLANs are now in my database.
Notice there's no ports that are associated
with the VLANs on DSW1.
Why is that?
Because I don't have any end users,
any access ports.
Only access ports show up here.
Ports that belong to what?
A single VLAN, like VLAN10,
or a port that belongs to the voice VLAN.
None of those ports are there.
All my ports are trunks,
but the switch still has to know about the VLANs
or it can't pass those VLANs on the trunks.
Now if we look at our output of
showing a trace trunk,
we'll see that those VLANs are now listed in our output.
So if you're ever looking at this output on an exam as well,
or in the real world,
you're like, why aren't they showing up?
Why aren't they showing up?
It says all the VLANs are allowed,
but none of them are showing up.
Nobody trained you about them.
Once you train your device about them,
then they show up.
So we're going to do the same thing with DSW2 now.
So why might a trunk not be working?
Well, a trunk might not be working
because the VLAN doesn't exist.
You see the dependency?
You see the relationship there?
And why might a VLAN not be working?
Because the trunk is not allowing that VLAN.
So that's what we're going to talk about next.
I think that's a good idea.
All right, so just so we're aware folks,
before we move on to the next thing
I want to talk about with trunks,
let's get back to some of this output
and make sure we understand what we're reading.
So if I type in do show interface,
can you give it, Ethan,
at one slash zero slash 21 right now?
Switchport.
So what do we have?
Administrative mode means I typed in
switchport mode trunk.
So this is a trunk.
So if you saw something like dynamic desirable
or dynamic auto,
and you saw trunk,
then that means you successfully negotiated a trunk.
But if you saw something like dynamic auto
or dynamic desirable,
and you saw static access,
then that means no trunk has been formed.
So the administrative mode means
what have you configured
or what is the default value in the operating system?
And this is what it's actually operating it as.
So the only two options for here
are trunk or static access.
Whereas up here,
you have static access, trunk,
dynamic auto, dynamic desirable.
And then you've got your encapsulation.
So if this said 802.1Q on this side
and the other side says ISL,
then you know you've got an encapsulation mismatch.
They have to both be the same.
So administrative trunking means
this is what's configured on the device.
This device only supports .1Q,
so that's all you would see there.
Let me rephrase that.
ASW1 and ASW2 only support .1Q,
so that's all you would ever see there for ASW1 and 2.
But somebody like DSW1 and DSW2,
they support ISL and .1Q.
So by default,
what you would see is negotiate there.
So when it says negotiate,
that means you're negotiating .1Q versus ISL.
And that only works if DTP is on.
If DTP is off,
then you cannot negotiate your encapsulation
because the negotiation of encapsulation
relies on DTP as well.
So if you're going to shut off DTP,
then you've got to manually set your encapsulation
by typing in, in this case,
switchport trunk encapsulation .1Q.
And then our operational mode
is whatever we've configured.
And then DTP is off
because we typed in switchport nonegotiate.
So if we look at the output now,
do show interfaces trunk,
what I want you to notice here
is that all your ports are listed,
and then those ports are listed
by the mode they're running in.
So on means trunk, desirable means desirable,
auto means auto.
The encapsulation, our native VLAN,
we're going to come back to that later.
But down here, notice how it says by default,
every single VLAN is allowed on a port.
So by default,
every single VLAN is allowed on your trunk link.
Now, is that what we want?
Is that what we want?
The answer to that is no, we don't want that.
One, it could become a security issue.
Two, it can become a performance issue as well.
I'm going to come back to that momentarily.
But what I want you to realize
before we come back to that
is that even though all VLANs are allowed on your trunk,
take a look down here.
It says VLANs allowed and active.
In the management domain.
What does that mean?
It means that only these VLANs
are allowed to use the trunks.
So even though all VLANs are allowed,
only the ones I know about
and are active are actually allowed.
So not all of them are truly allowed in the end.
You have to read this from top to bottom.
Which VLANs are allowed?
All of them.
But only the ones I know about locally
in my VLAN database
and are active.
So if I know about them,
but somebody's suspended the VLAN
or shut down the VLAN,
then it would not be listed here.
However, that is still not the ultimate deciding factor.
The ultimate deciding factor
is actually Spanning Tree Protocol.
Look what it says here.
VLANs in the Spanning Tree forwarding state
and not pruned.
So even though all VLANs are allowed by default,
if and only if I know about them,
if and only if Spanning Tree Protocol says so
and VTP says so.
That's right.
So why might your link
not be forwarding traffic
for a certain VLAN?
Because Spanning Tree Protocol says no.
Or VTP says no.
See that relationship there?
That's incredible.
I'll come back to this
when we have our Spanning Tree discussion tomorrow.
But just because all VLANs are allowed
and just because you know about it
doesn't mean it's actually allowed.
Because Spanning Tree Protocol is the final say.
But you might want to control this manually.
Now in the end,
even if you control it manually,
it might not have much of an effect
on Spanning Tree Protocol's decision.
But what you can do
is basically control what's happening up here,
which then has a trickle-down effect
to here
and a trickle-down effect into here.
So if I turn around and say,
you know what, I only want to allow VLAN 10 and 20
on a certain link,
then only VLAN 10 and 20 will be allowed on that link,
which then affects this,
which then affects this when it's all said and done,
which then actually has an effect
on Spanning Tree Protocol as well's decision-making process.
So by filtering your VLANs on your trunks
can actually change
what Spanning Tree Protocol is doing as well.
Right.
Oh my gosh.
All right, so let's take a look at the command,
or let's take a look at why we might want to do that.
So it is recommended
to filter VLANs on your trunk links.
Let's repeat that.
It is recommended
to filter VLANs on your trunk links.
One, for security standpoint.
Two, for performance reasons.
So,
let's say we have
a broadcast message that leaves
VLAN 10.
Now let's,
not leave VLAN 10,
is in VLAN 10.
Now what I want to do here
is I want to pretend
Spanning Tree Protocol
is not running anywhere.
So,
let's say
Spanning Tree Protocol
is not running anywhere.
Which it would never happen, okay.
But let's pretend it's not.
Just so that way there we don't get confused
by Spanning Tree Protocol right now.
I'm trying to give you a story
that's going to help you understand
why we want to filter.
All right, so what's going to happen
if we have a broadcast frame in VLAN 10?
It's going to get flooded out all ports
in that same VLAN
except the port it came in on
and all trunk ports
right?
So,
in my case that's all my trunk ports
because if you look here
I'm allowing VLAN 10 on everything, right?
Everything on all my devices.
So that means it's going to get
sent out, sent out, sent out, sent out.
That's fine, right?
That's fine.
Don't worry about loops here.
Don't worry about loops right now.
Now,
the question is,
is when DSW-1 gets
these two messages
what VLAN do they belong to again?
They belong to VLAN 10.
Let me ask you this question.
Do they need
to go this way, yes or no?
Do they need
to go this way?
Those broadcast frames.
Look at the topology.
If a broadcast frame is generated in VLAN 10
it would have to go to everybody
in VLAN 10.
Correct?
Correct.
So to answer my question of
does it need to be sent here?
All you have to do is say
is there anybody in VLAN 10 down here?
If the answer is yes
then you have to send the traffic that way.
If the answer is no
then you don't have to send
the traffic that way.
Therefore,
I'm not sending VLAN 10 traffic
somewhere where it doesn't need to go.
One,
security.
Two,
performance improvement.
Why?
Because now VLAN 10 traffic
will never be on these links.
Or,
think about the VLAN 10 traffic
that comes here.
What if I did the same thing here?
Therefore,
it would never be sent that way
either the VLAN 10 traffic
because it's not needed.
It's not needed.
So now,
I ensure that no VLAN 10 traffic
comes here so therefore
VLAN 10 traffic could never
now consume bandwidth on those links.
Never allow VLAN 10 traffic here.
Again,
never have the ability to consume
bandwidth on those links now.
So all that bandwidth is for VLAN 20
and 50 and 200 instead.
VLAN 10 will never interfere with that.
Also,
the VLAN 10 traffic never comes down here
to accidentally get intercepted.
When I wouldn't want it to be.
So,
filtering is a great way for us
to improve performance
as well as improve security.
So over here on DSW-1,
just for fun,
let's think about what we could do
to some of these interfaces on DSW-1.
So going this way,
I would want to allow what?
Allow
10,
20,
and 200.
I would not want to allow 50
or any other VLAN.
I only need to allow the VLANs
for the VLANs that live down there.
So allow 10,
20,
and 200.
Same thing here,
10,
20,
and 200.
Over here would be what?
20,
50,
and 200.
20,
50,
and 200.
And you can do the same thing
on all those other interfaces.
So let me just show you the result
of doing that on DSW-1.
So on DSW-1,
interface range,
gigabit ethernet,
one slash zero slash
21 to 22.
And we'll type in switchport,
no, no.
We'll type in,
yes, it is.
Switchport trunk allowed VLANs.
So switchport trunk allowed VLANs.
And then I can just list my VLANs.
I can just list them.
So let's go ahead and list
10,
20,
200.
Now we type in,
do show interfaces trunk.
We'll see in our output
that it has changed,
which has then changed
what's going on in here,
which then has probably,
yes, changed what's going on down here
from Spanning Tree's standpoint.
Now notice,
I did not include VLAN1,
did I?
Is that a problem?
No, it's not.
Absolutely not.
Because the control traffic
can still use VLAN1,
even though it's not on the link.
Always remember,
when you're filtering,
you're filtering the end user traffic.
You're filtering the voice traffic.
That's what you're doing here.
You're not affecting control traffic,
like Spanning Tree protocol messages
or DTP messages
or VTP messages
or CDP messages
or LLDP messages
or anything like that.
That's control traffic.
You're not affecting that.
You're just affecting what?
You're just affecting user traffic.
So if a user accidentally
ends up in VLAN1,
they're not going to be able
to cross this link down.
Ooh, there's that security, right?
If a user accidentally
ends up in VLAN1,
they're not going to be allowed
to use the link.
Their traffic's going to stay stuck.
Where?
Down here.
So if somebody manages
to connect themselves
to our switch port
and end up in any VLAN
other than 10, 20, or 200,
they're stuck.
They can't get up
to the distribution layer.
So again,
a little bit of security as well
when it comes to that.
So you get both security
and performance.
So the command I showed you there
was straightforward.
It was just list the VLANs
you want to allow.
All right.
Now let's say we wanted
to modify this list.
Let's say we wanted
to add VLAN50 to the list.
Be careful.
This is not how you do it.
This overwrites
what was already there.
See, the previous command was what?
This was the previous command,
and now I replaced it
with that command.
I just overwrote everything.
So if we look at show interface trunk,
you'll see I just messed everything up.
I wanted to add VLAN50.
So let's go back
and put this command in.
Exactly.
We have to have the right keyword.
So the right keyword for that
would have been VLAN add 50.
Now when you look at the output...
Excuse me.
You didn't take...
Oh, I forgot to put add.
Did I really?
Let's try that again.
Add 50.
There we go.
All right.
Now that you see what I've done there,
there you go.
Add 50.
Be mindful of that.
So I'm showing you these different options
for the command
just in case you need to
pull this out of your back pocket
on a certification exam.
Because really in the real world,
what would I do?
I just recreate my list
of VLANs I want.
Why?
Because I know that I'm not making a mistake.
I don't have to worry about syntax
and all that stuff.
Here's my list of VLANs.
Good enough.
Double checked.
Good, I'm fine.
But if you want to get creative
with these different keywords,
you absolutely can.
And I would encourage you
to know them for the exam.
For example,
what if I said to you
I wanted you to allow VLANs
10, 20, and 200 only.
But you had to...
You had to...
You couldn't use.
You could just list your VLANs.
Well, then you have to remove
the ones that aren't there, right?
For example,
remove 50 to get that out of there.
That's how you would get it out of there.
Or you could just retype your list
if you really wanted to,
which is what something I would do.
I copy and paste,
remove what I didn't want,
and so on and so forth.
You can do accept,
which means what?
Accept means
allow all these VLANs,
allow every VLAN,
pardon me,
except the ones I've listed.
So if we turn around and we say
accept 10, 20, and 200,
well, then you'll see
what the result of that one is.
Everything except for those three.
So you can see how these keywords
make a big difference
as to what the result is.
And I'd highly encourage you to know
the differences on the certification exam
for each of those keywords
in case it shows up.
So if you just do your list,
it replaces whatever list you had before.
If you add,
if you use the keyword add,
it adds to your current list.
If you type in all,
it goes back to the default.
It just lists every single VLAN.
If you do accept,
it's every VLAN
except the ones you've listed.
If it's none,
then it means no VLANs allowed
on the trunk link.
So that's a really great way
to shut down your trunk link.
If you ever are having issues
and you need to shut down your trunk link
to stop traffic flow,
you can type in
switchport trunk allowed VLAN none,
and that would shut it down.
You can also shut down the VLANs too
on all the devices,
but this might be a quick way to do that
or just unplug the cable,
whatever.
And then remove
as we saw is to remove one.
So just be mindful of that.
Pay attention to the scenario.
Pay attention to the situation.
And that'll help you get through
whatever you need to get through
on the certification exam.
Yeah, so Casey,
is there a difference between using add
and just overriding the list?
Again, it's a personal preference.
I have a tendency to overwrite the list.
I really do.
But here's the thing.
If you forget the add keyword,
then you overwrite it,
and that's the thing.
So in my opinion,
one's not safer than the other,
in my opinion,
only because if you accidentally
forget the add keyword,
you're overwriting it
with a single VLAN
or the ones you wanted to add,
but you just overwrote it.
So the add one can be safer
if you make sure you put in
the add keyword.
But in the end,
the result's going to be the same
whether you just add something
or you overwrite your whole list.
It's up to you.
No.
None will remove everything.
Yeah.
So switchboard trunk allowed VLAN none.
So you'll see it's none.
Everything's done.
Right?
But again, remember,
this is always about what?
User traffic.
So voice traffic,
end user traffic,
stuff like that.
Control traffic's still allowed.
So control traffic's still
not affected by that.
Right?
So there's just an example, folks.
I'm going to remove that, though,
because I don't want it to interfere
with my Spanning Tree discussion
that we are going to have tomorrow.
I want to make sure that I have
every single VLAN listed
so that way we can see
Spanning Tree Protocol
in full force tomorrow.
But always remember that in the end,
as you manipulate this list,
you manipulate Spanning Tree Protocol as well.
You manipulate Spanning Tree Protocol,
you can also manipulate the list.
All right.
Lastly,
we have to talk about the native VLAN.
All right.
So we've just looked at filtering.
So I do have some slides on filtering.
So just this one slide,
basically we did that example
and at that output there.
All right.
Let's talk about the native VLAN now.
This is always a difficult discussion
because we're dealing with something
that is part of 802.1Q.
Well, not really, but yes, it is.
So 802.1Q is what?
802.1Q is a IEEE standard.
And what do you think are the odds
that Cisco implemented the standard
100% the way they should have?
What do you think the odds are
that Cisco implemented the standard 100%
as they should have?
Truthfully, the odds are like so low, right?
They got a lot of things right,
but a lot of things they adjusted
for their own benefit, for their own sake.
So here's the deal when it comes to VLANs
on switches, according to VLAN standards.
Every port, every port, no matter what,
has to belong to a VLAN.
That's the rule.
Every port has to belong to a VLAN.
So when you are working with 802.1Q,
the standard, and potentially on other vendor switches,
you actually place your port in a VLAN
that you've dedicated for your trunks.
So we'd create a VLAN, let's call it VLAN 333,
for fun.
And I put all my trunk ports in that VLAN.
If I don't, then my trunk ports are in VLAN 1,
which would still be acceptable,
but not a best practice, okay?
So your trunk ports are in VLAN 1 by default,
according to the industry standard,
our default Ethernet VLAN.
So if you don't want it to be that,
which is recommended not, you create another VLAN,
use it for your trunks,
you put all your trunk ports in those VLANs.
And what do we call that?
We call that the port VLAN ID, right?
Every single one of our ports has a port VLAN ID.
VLAN 10, VLAN 10, VLAN 20, VLAN 20, VLAN 50, VLAN 50.
They all have port VLAN IDs.
Well, so do your trunk ports.
So this port belongs to VLAN 333.
And so therefore, if traffic arrives
that belongs to a different VLAN,
so in this case, VLAN 10,
what do we have to do
in order to send it across a port
that is part of VLAN 333?
We have to tag it with what?
An 802.1Q tag
and put the VLAN number in that tag.
So that way there, when it goes across the trunk link,
when it arrives at the other side,
and this port would be in 333,
it comes to the other side,
the same thing happens.
This port would be in 333.
It comes to the other side.
The switch looks, says,
oh, I have a frame that just came in port VLAN 333.
Oh, but look, it's 802.1Q tagged.
Looks at the tag and says,
oh, this frame belongs to VLAN 10.
Is that difficult to understand, folks?
Was that difficult, yes or no?
To me, that's super simple.
It's basically what we talked about a while ago, right?
Let's add something to this.
Let's say you have a device here, a PC,
that is in VLAN 333, okay?
It's in VLAN 333.
So if traffic arrives now from that PC to the switch,
and it needs to go across the trunk link now,
do we have to tag it if it's already in VLAN 333?
No, right?
Because if I'm already in VLAN 333,
I don't have to tag it
because if I send it across the link without a tag,
what does the switch assume the VLAN is?
333 because that's the port VLAN ID of itself,
so it assumes it's part of that, which works perfect.
So if you're in the same VLAN as the trunk links,
which typically you wouldn't do,
but if you add that, you don't tag that traffic.
If you are in a different VLAN than the trunk links,
then you tag the traffic.
It works perfect.
It's exactly what we want.
But Cisco says that's not how we do it.
We kind of do it that way, but we don't do it that way.
For example, when we created our trunks, folks,
did we put them in a VLAN?
Nope.
Right?
Who did we configure?
17, 18, 19, 20, 21, 22, 23.
Look, they're not even in a VLAN.
They're not even in a VLAN at all.
So that goes against the IEEE standard already.
What did we do?
We typed in switch port mode trunk,
or maybe we used dynamic desirable,
or maybe we used dynamic auto, whatever, right?
A trunk was formed.
So which VLAN does your ports actually belong to?
None.
Okay.
So how does it know whether it should tag the traffic or not,
then, based on the native VLAN?
Well, what's the native VLAN?
It's a number.
That means what?
Native VLAN.
What does that mean?
It means it's a number.
It's a number.
What does that mean?
It means no tags.
Untag traffic.
But what does that mean?
It means if you belong to the native VLAN,
we won't tag you on trunks.
But if you don't belong to the native VLAN,
we'll tag you.
So you just made up this arbitrary number?
Oh, no, no.
We made it number one by default.
Wait, so you're telling me the default Ethernet VLAN is one
and the native VLAN is also one?
Yep.
Can you confuse me anymore?
Absolutely we can.
So we type in the show interface trunk here,
and what do you see?
We see that the native VLAN is listed as VLAN one right here.
Let's be very clear.
The native VLAN is different than the default Ethernet VLAN.
Because remember, the default Ethernet VLAN is VLAN one.
Yes, it is.
All ports are in that VLAN by default.
Your trunks, before they were trunks,
were part of that VLAN by default.
When you type in switchboard mode trunk,
essentially it says you don't belong to a VLAN anymore,
but you belong to this cool thing called the native VLAN.
Why didn't I just stick with the standard and go port VLAN ID?
Because that's not what Cisco did.
So you don't belong to a specific port.
Now you belong to a native VLAN.
So I want you to think going forward,
to simplify this for yourself, this native VLAN,
just think of it as the VLAN number of the trunk link.
That's it.
Just think of it that way.
That's the easiest way to simplify this.
That is the VLAN the trunk belongs to.
Now you don't even have to create the VLAN, by the way.
I could actually change my native VLAN to something else
and not even create the VLAN because most of the time you're not even going to
have traffic in the native VLAN,
just like you would not have traffic in the trunk VLAN,
like we did in our previous little example here.
It doesn't make sense to have servers in the same VLAN as your trunks,
unless you have no choice.
So it's the same idea here.
We really don't want to have end users, devices, stations, anything,
services in the native VLAN.
Think of the native VLAN as the VLAN the trunks belong to.
So now if users are part of the native VLAN,
then their traffic doesn't have to be tagged.
But if users are not part of the native VLAN,
then their traffic has to be tagged.
So the end result is the same.
The end result is the same.
But it's trying to wrap your head around this concept that makes it the
hardest because what is the native VLAN?
It's just a virtual construct, a virtual VLAN.
Give me something tangible to hang on to,
like the port VLAN ID of the IEEE, that makes sense.
Your port is in VLAN 33.
But if you ask Cisco what port is my VLAN in,
they're going to say nothing with the trunk, nothing.
It doesn't belong to a VLAN.
Okay, but then what's the native VLAN?
Oh, it's just about tagging and untagging traffic.
Okay, well, give me something concrete here that makes sense to me.
Give me something that's going to help me understand this so I can get
your questions right on a certification exam and build my networks properly.
Daisy says, so if you change the native VLAN without creating the VLAN,
therefore any traffic in the native VLAN would just get black-holed,
essentially?
Yeah, that's exactly what would happen.
And that's not a bad thing because if anybody ends up in your native VLAN,
that might be a bad thing because the recommended best practice is never,
ever use your native VLAN unless you're forced to do it for some reason.
And most companies will never use their native VLAN, not for nothing,
for nothing, and you shouldn't.
Everything should be part of a VLAN that gets tagged.
And just let the native VLAN be the what?
The VLAN that the trunks live in.
That's it.
That's the easiest way to do it, right?
It's the simplest, safest, best way to do it.
And so native VLAN frames are carried over the trunk untagged.
So if you have native VLAN frames, that means you have devices in the native VLAN.
So, for example, by default, the native VLAN we set is one.
Okay, that's the native VLAN.
By default is one.
And so if I had a server here that was in VLAN one, then its traffic arrives.
Ooh, you're in VLAN one, therefore you can go across untagged.
But you would probably never,
ever have a device in the native VLAN or the same VLAN as the native VLAN.
So let's put it that way.
So traffic here for VLAN 10 comes here.
Now we got to tag it before we send it across, so it's in VLAN 10 on the other side.
So traffic not in the native VLAN gets tagged.
Traffic in the native VLAN gets tagged.
But you don't even want to be using the native VLAN.
That's best practice.
You said the default is one, so know this for the exam.
Know this for the exam.
These are the things I want you to know.
If you don't know anything else I said on the previous page, don't worry about it.
You memorize this, you got all the questions right.
I'm serious.
You memorize this, you get all the questions right.
Look at this.
Native VLAN must match on both ends of the trunk.
That's important.
Somebody mentioned that earlier.
So, for example, if this was VLAN one and this was VLAN 99,
so native VLAN one, pardon me, native VLAN one and native VLAN 99,
then let's say here we have a server that's in native VLAN one,
or in VLAN one, which is also the native VLAN for our trunks.
Then traffic arrives here.
And then what happens to the traffic?
Do-do-do.
And untagged.
Remember, it's untagged.
Do-do-do-do-do.
Now you're part of VLAN 99.
Wait a second.
You just went from VLAN one to VLAN 99.
You did what is called VLAN hopping.
A native VLAN mismatch will merge traffic between VLANs.
So by messing up your native VLANs,
you cause traffic to jump from one VLAN to another VLAN.
Now cyber criminals used to take advantage of this back in the day.
It used to be called a native VLAN hopping attack.
But that's pretty much stopped today by our devices.
Because if you ever have a native VLAN mismatch today,
CDP is going to just get mad at you.
LLDP, it's going to detect that there's an issue here on the trunk.
So it's going to send messages saying, hey, hey, hey, this is wrong,
this is wrong, this is wrong.
Also, spanning tree protocol is going to lose its mind.
Okay?
It's going to lose its mind for both VLAN one now and VLAN 99.
And it's essentially going to block those ports.
So traffic won't even be allowed to flow.
So by these protocols now being able to recognize this issue,
and it's been around a long time.
I'm not saying now like, oh, it happened yesterday.
No, ages ago.
These VLAN hopping attacks are less likely to occur in your environment.
So if you make the mistake, your device is going to yell at you now.
But for the exam, obviously all logging messages are going to be disabled,
everything is not going to be shown to you, anything like that,
and log messages.
So if one side is configured for one and the other side is configured for some
other number, you just have to know, hey,
that's a native VLAN mismatch based on what Raymond told me.
So if this side, for example, is one, let's go with 20.
So this side is one.
And then if we go over to ASW1, that would be this port here,
was let's say 99.
Then we have a native VLAN mismatch.
So let me do that configuration for you.
So interface, gigabit Ethernet, one side zero slash one.
What did I do wrong?
Oh.
Now we'll type in switch port trunk native VLAN 99.
So notice I don't have VLAN 99 on my platform.
I don't have VLAN 99 on my device.
We never created it.
Do show VLAN brief.
But I'm still using it as a native VLAN.
And it didn't even create it for itself.
That's okay.
That's perfectly fine.
It just means now that traffic for VLAN 99 can't flow across the link
anyways.
But if we go over to somebody like DSW1,
we'll see here that it's configured for VLAN 20.
And if we go to ASW1, do show interfaces trunk.
Did I forget to hit enter?
Did it not take it?
Did I configure it on the wrong interface?
What interface did I configure?
One?
Did I configure one?
Silly me.
Oh, my gosh.
45.
Let me try that again.
Oh, my gosh.
I just configured my end user interface as native VLAN.
Not good.
Bad Raven.
Bad.
Go clean up.
There you go.
So native VLAN 99 on this side.
So, for example, for the exam, being able to look at this and say,
wait, this number doesn't match this number here.
Because those are the interfaces that go together.
Then you absolutely want to make sure that you, you know,
that would be the answer to the question if there was a problem.
So we've got one here and 99 here as an example.
So they've got to match.
You're going to have problems.
I'll see some messages.
There you go.
So we're starting to get CDPs starting to yell at me right now in
Spanning Tree Protocol.
We'll probably block some ports here momentarily for both of those VLANs.
But wait a second.
I'm not even allowing them.
Let me see.
One.
That'll start blocking one.
But 99 is not even allowed, so it's not going to have to worry about it
because there's no Spanning Tree topology right now for VLAN 99.
Yeah, so hopping is leakage.
Absolutely.
So is it best to use a native VLAN other than just one for chunking?
Is there a security reason?
So let's go to the slides,
and we'll look at the very bottom one that I haven't covered yet.
It says change the native VLAN to a VLAN you're not using.
There you go.
All right, so is it best to use the native VLAN other than one just for
chunking?
Absolutely.
That is the recommended best practice.
So one of the things you would do is you would make sure you're not using
VLAN one and you are basically using a VLAN that you will not use in your
environment.
You set it as the native VLAN on all your chunk ports,
and that adds a little bit of extra security.
Definitely don't use VLAN one because cyber criminals love trying to get
into that VLAN one because it's the default for everything.
So the moral of the story for this is you don't want to use VLAN one for
your native VLAN,
but you also don't want to use VLAN one for anything else.
That's right.
If you took a Cisco security course,
it would be don't use VLAN one for user traffic.
Don't use VLAN one for voice traffic.
Don't use VLAN one for your management traffic.
Don't use VLAN one for anything.
Get all ports off of VLAN one.
Every single port off of VLAN one.
That's what your recommendation is.
And for the native VLAN,
use a native VLAN number you're not using.
Set it on all the chunk ports.
Make sure they all match.
Then away you go.
Yeah.
So hopping would be leaking from one VLAN to another VLAN.
Absolutely.
All right.
So here, for example,
I created a VLAN in this case,
but as you saw in my demo,
I didn't do it,
but that's okay.
You don't have to do it.
It's still going to work for you.
But if you wanted to create a VLAN 99,
make sure you name it the native VLAN so you know that that's what you're
using it for.
And then go ahead.
Now don't use 99 in the real world and don't use 999 in the real world
because Cisco's documentation and Cisco Press textbooks use 99 and 999.
So CyberKernel is going to try those next after one.
So always go with some random number documented as your native VLAN and go
with that instead.
All right.
And then now that we have our native VLAN configured,
here is ASW1, 99 on both links.
And then same thing with DSW1.
You got 99 on both those links as well.
So you want to make sure you're doing it on all of them.
Now in this example,
as you can see,
I'm not doing any type of pruning or filtering down below.
But what it comes down to is remember that if you are allowed,
if you did create your VLAN 99,
if you did create a VLAN for your native VLAN,
and you're not going to have any traffic on that,
which is the recommendation,
so then I would filter this off with the commands we saw earlier.
So, you know,
switch port trunk allowed VLAN 10, 20,
whatever ones you have,
but don't allow 99.
And if you're not using one,
then don't allow one.
That's another recommended best practice.
So only allow the VLANs.
You absolutely have to allow across those trunk links based on traffic flow.
Do we have traffic in that VLAN?
Yes.
Then it needs to be allowed on that link.
If not, take it off.
It's a recommended best practice.
All right.
That was a lot.
That was a lot for trunking.
For some of you,
it was a review of CCNA with a little bit more,
but not much more.
For some of you,
it's been a while since you've dealt with trunking.
So a lot of stuff to review there
and make sure you're ready for the certification exam.
Thank you.