At this point, we can leave ISL behind and focus in on what we use in modern
networks,
which is 802.1q.
And so let's say we configure a couple of switches, and we've got maybe 100 V
LANs on
both of these switches.
And hey, now with trunking, of course, we can only just connect maybe a single
connection.
Maybe we'd use an ether channel here, but either way, it's going to be a single
logical
layer to link, which is now going to be configured as a trunk. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
layer to link, which is now going to be configured as a trunk.
And by default, all VLANs are going to be carried across this trunk.
So they're all going to be allowed.
Now in our situation with 100 VLANs, we might want that.
We might want all 100 VLANs allowed.
But even at that point, let's say we get onto this switch and we decide, you
know, I'm going
to add a VLAN, I'm going to add that 101st VLAN.
Well, because all VLANs are allowed on the trunk, this automatically gets added WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, because all VLANs are allowed on the trunk, this automatically gets added
to this
trunk.
And maybe 101, whatever that idea is, it just doesn't exist over on the other
side.
Meanwhile, I'm sending broadcast traffic for that VLAN across that trunk link.
This is why we typically don't want to rely on this default behavior.
This default behavior can create inefficiencies.
We don't necessarily want to extend every VLAN because that VLAN might not
actually be useful
or even used at all on the other side. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or even used at all on the other side.
So I want to be intentional about this.
And so much of network configuration comes back to us wanting to be intentional
.
What VLANs do I want on that trunk link?
Do I want them all?
And even if I want all the ones that are currently configured, do I really want
every
future VLAN to be automatically added to that trunk link?
And again, the answer is usually no.
So how do we be intentional about this?
Well, we're going to create an allowed list.
This allowed list is going to specify which VLANs are allowed and which ones WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This allowed list is going to specify which VLANs are allowed and which ones
are not.
And this uses a pretty simple command.
We're going to use that switch port trunk allowed command.
This command gets used a lot in the real world as well as in CCNA and CCNP
studies.
And because this is a very big part of creating clean network configurations
and clean network
design is controlling the VLANs and where they all go.
I want to make sure that we're limiting again the broadcasts that are getting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I want to make sure that we're limiting again the broadcasts that are getting
sent out.
Want to limit the number of spanning tree protocol instances.
Want to prevent VLANs sprawl.
So all of these can start to get out of hand if we just put VLANs everywhere
and allow
them on all of the trunks.
So switch port trunk allowed and then I'm going to specify the keyword VLAN and
then give it
a list of VLANs.
So something like 1 to 10 or 13 through 15, whatever we end up putting in there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So something like 1 to 10 or 13 through 15, whatever we end up putting in there
is going
to be allowed.
And Cisco's really good about allowing us to configure a bunch of different
ranges separated
by commas that is certainly part of the syntax of the command that we're going
to want to
be able to play with in a lab environment when we get to our lab later.
So now comes a tricky type of scenario because it's great that we have this
allowed list,
but now we might need to add or remove VLANs from the allowed list. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but now we might need to add or remove VLANs from the allowed list.
And this is where we get into some pretty notorious, notorious storytelling
about this
scenario.
Because I like most people who've been in the industry as long as I have can
tell you a
story or two about accidentally changing the VLAN list.
What do I mean by this?
Well, here's what I mean by it.
The command to add or remove a VLAN is very similar to the command we just used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The command to add or remove a VLAN is very similar to the command we just used
.
So switch port trunk allowed VLAN and then I have to use the add or remove
keyword here.
And then I specify the VLAN ID or VLAN IDs that I want to add or remove.
This right here, remembering to include that command is going to be potentially
a life-saving
opportunity so to speak, where I remember to use it and everything went smooth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
opportunity so to speak, where I remember to use it and everything went smooth
or it
could potentially completely torpedo a network cut over.
So the story that I'll tell very briefly is that I did have an engineer on my
team who
had a situation where he was adding a VLAN to two links that went into a switch
that
was located far away.
And so he got onto this switch and happened to, of course, forget to use the
add command.
When you forget to use the add command, what command are you entering? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When you forget to use the add command, what command are you entering?
You're entering this command where you're basically overriding the existing V
LAN list.
So instead of saying to add VLAN 10, you just say the only allowed VLAN is VLAN
10.
So by forgetting the add keyword and putting it on this link and then logging
in to this
interface and putting it on that link, the access to the switch was lost.
And fortunately, it was only about a 30 or 40 minute drive, I think, that he
had to drive
out there.
But once you eliminate the management VLAN on those two links, you're done. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But once you eliminate the management VLAN on those two links, you're done.
You can't access that switch anymore.
And so that is the type of stories that you'll hear around this.
And if you've never had to worry about that yourself, then learn from the
mistakes of
others because this is a very common mistake that gets made and it can result
in people
having to get in cars and drive great distances to access a device that we
accidentally locked
ourselves out of. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ourselves out of.
So when we're modifying the allowed list, make sure to remember that add a
remove keyword.
And hey, this is something that is a good idea to play around within the lab
because
it will translate over to real world configurations.
Now we mentioned the native VLAN with 802.11 or 802.1Q, sorry, with 802.1Q, we
get the
concept of the native VLAN, whether we like it or not.
And the key thing here is that it is going to be untagged. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the key thing here is that it is going to be untagged.
So we don't necessarily want one of our VLANs to be untagged.
And there's good reasons for this.
For one, security is a big concern.
Some threat actors are able to use native VLANs for a variety of attacks.
And the other one, as we mentioned, is quality of service.
I can't carry my layer two tags inside an untagged frame.
And so I don't want to necessarily use the native VLAN.
In fact, the recommendation is to avoid using the native VLAN in real world WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, the recommendation is to avoid using the native VLAN in real world
networks.
So what do we do here?
Well, we have two different solutions.
First of all, the most common one is to create a dummy VLAN and then map that
as the native.
So for example, I could just specify that I want the native VLAN to be VLAN
4000 and
then I don't actually use VLAN 4000.
That would be the idea there.
The second option is kind of interesting and one that we don't see too often. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The second option is kind of interesting and one that we don't see too often.
And that is to simply tag the native VLAN.
This is an option.
And there is a global command to enable this.
It is simply VLAN.1Q tag native.
Now the downside to this, as cool as this option sounds, is it must be enabled
on all
switches in the layer two domain.
Otherwise, this is going to cause a lot of problems. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Otherwise, this is going to cause a lot of problems.
So I will say from my perspective, I have seen far more of option number one be
used
in the network because it's easier to maintain something like that.
And it's a lot easier to maybe forget to add this native tagging command to
every single
switch in the environment.
But either one of those will get the job done.
Now, how do you change the native VLAN?
If we want to use option one, for example.
Well, just like over here on the left, we've got some switch port trunk
commands and we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
commands and we're
going to say switch port trunk and then native VLAN and then I specify the VLAN
ID here.
And I just need to make sure that I place this onto both sides and that it's
synchronized.
Now importantly, I don't have to have it synchronized on the entire switch.
It just needs to be synchronized between switches.
So for example, I could have a native VLAN on this side of 10 and a native VLAN WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for example, I could have a native VLAN on this side of 10 and a native VLAN
of 20
on the right.
As long as these two switches agree or these two ports and interfaces agree on
VLAN 10
on the left and 20 is agreed to on the right, then we're good to go.
Notice the switch in the middle is managing native VLANs or different native V
LANs on
different ports and that's perfectly fine.
It's not a global configuration.
This is locally significant to the interface.