(light music with digital sounds)
- In the last video, I introduced you to the
concept of VLAN Trunks.
Which is really just on a switch, a formal way of
identifying different broadcast domains that that one
switch is keeping track of, and keeping isolated
from each other.
In the context of VLANs, we also learned that
all the devices that are in one VLAN are also at
layer three in the same IP subnet.
Now the switch is not aware of that.
If we're talking about just a regular layer two switch,
the switch does not really know anything
about IP and subnetting.
All it knows is that this group of ports here
is contained in one broadcast domain.
This group of ports is in a different broadcast domain.
And the two are not allowed to talk.
Now that being the case, what if you have a situation
like this, and I have worked this up here in GNS3
so you could replicate this if you want.
Where I have two VLANs.
So in this particular case, I have VLAN 1 here and here,
and it's separated between two different switches.
So if all I had was VLAN 1, then this connection between
the switches could also be placed in VLAN 1,
and these guys would be able to communicate.
And in order to make this more of a real-world scenario,
I've also incorporated DHCP server, which in this case
is my router.
Later on in some of the later videos when we talk a little
bit more extensively about DHCP, you'll actually learn
how to configure a router or a switch as a DHCP server.
The configuration's pretty easy and it's the same whether
you do it on a router or on a switch.
Usually in real life, you would have in a regular network
a real server like a Windows server or a Linux server,
or something like that, acting as your DHCP server.
But in some smaller networks, you can get away with just
having your router or your switch double up as a DHCP server
so that's what I'm doing here to make this simple.
So these two PCs here are going to have to get their
IP information from the DHCP server.
You can see that they are going to be in the 1.1.1.x network
and the server itself, the router, is 1.1.1.1.
Now to make things a little bit more interesting,
I also incorporated a second VLAN.
VLAN 2, as you can see right here, and that's also
split across the switches.
Now that poses an interesting dilemma.
Because I only have a single connection here
between these switches.
If I put that connection into a VLAN 1, and I put this
connection here between the switch and the router
and VLAN 1, then these two PCs will be happy.
We'll have one big broadcast domain that will, they'll
be able to communicate with each other via ARP.
Their DHCP broadcast will be able to go down here to the
router and they'll get their DHCP information.
Well that'll leave the people in VLAN 2 out in the cold.
So for VLAN 2, one option I could do is I could connect
another connection between these switches,
put that in VLAN 2.
Connect another connection from the switch to the router.
Put that also in the 2 subnet.
And then our VLAN 2 people would be happy.
They could communicte across the second link.
They could get to their DHCP server across this link.
Now that might be okay if we're only talking about two VLANs
but in a real network, most likely you're going to have
dozens, if not hundreds of VLANs, depending on how large
your network is.
And you're not going to have enough scalability to just
assign individual ports for something like this.
So in this particular case, it's a more scalable solution.
If you haven't heard that term scalable before,
what I'm talking about is designing your network in such
a way that it has room for future growth.
It has room to add more subnets in the future, or room
to add more VLANs in the future.
So you're thinking about, what features can I use, how can I
configure things that will allow me to grow in
the future more easily.
That's what we mean by scalability.
So in this particular case, adding some extra links
isn't really an option for me.
So, what we need to do is we need to figure out some way
that this one link here between the two switches
is actually capable of being in more than
one broadcast domain.
You see, these access ports going to the hosts,
well an access port by definition is only in
one broadcast domain.
This access port right here is in the broadcast domain
known as VLAN 2.
And this access port up here is in the broadcast domain
known as VLAN 1.
But in the middle here, between the switches and from
the switch to the router, I have a need to actually put
those links into multiple VLANs.
And this is where the concept of VLAN Trunks
comes into play.
So a VLAN Trunk Port has two or more VLANs across it.
So look at the last bullet point here.
By default all VLAN traffic is allowed from a trunk port.
Now, we know that on the switch, let me ask you
a review question:
What was the default VLAN?
VLAN number "what" is the default VLAN?
Hopefully you said VLAN 1, that's right.
Now, what is the highest numbered VLAN that
you could create?
That was VLAN 4094.
So you had from VLAN 1 to VLAN 4094.
Now, all those VLANs don't exist by default on a switch.
The only ones that exist by default are VLAN 1, and then
those sort of VLANs in the middle, like 1002 - 1005,
and that's it.
So, what Trunk Ports do, is, as you create a new VLAN,
let's say you create VLAN 17, or VLAN 333,
before you even apply it to any access ports,
because remember using a VLAN is a two-step process.
You create the VLAN globally, config T, and then VLAN 25,
and VLAN 17.
Then, if you actually have any ports on the switch
connecting to hosts, you have to go to that port and say
switch port access VLAN 25, or switch port access VLAN 333.
But, even before you apply a VLAN to an access port,
the moment you type in VLAN 5 or VLAN 99, and that becomes
a VLAN in the switch,
if that switch has any functional VLAN Trunks, so now we're
talking about a different mode now.
Previously we talked about switchport mode access,
now we're talking about a different mode:
switchport mode trunk.
And when an interface is considered as a trunk,
whatever VLANs are on that switch are automatically
allowed to go across that trunk.
So if I've got five broadcast domains, VLANs one, two,
three, four, and five, all five of them will automatically
be carried by that trunk.
Now that raises and interesting question if we go back
to our diagram right here.
If this PC, PC 1
generates a frame,
actually let's forget about PC 1 for a second.
Let's take a look at PC 2.
If PC 2 generates a frame that needs to go across this trunk
and then go down here to PC 4, let's say it's a broadcast,
maybe he is sending and ARP request saying,
"Hey PC 4, I need to know what your MAC is."
Once that ethernet frame arrives here on fast ethernet 0/15
of ether switch 2, and let me go ahead and zoom in on that
a little bit.
Right there, okay, let's move this guy out of the way.
Once it comes in right here, switch 2 has to have
some way of knowing, okay this a broadcast that just came in
and I have actually two broadcast domains that I'm aware of,
VLAN 1 and VLAN 2. Hmm.
Which broadcast domain am I allowed to put
this broadcast into?
Because when the broadcast comes across here,
this ARP request, we don't want him to flood it into VLAN 1
because it originated over here in VLAN 2, so it has to be
flooded into VLAN 2.
So that means that as frames go back and forth across
this trunk, there has to be some way of identifying
which broadcast domain they belong to.
And 802.1Q has a very creative way of doing this.
802.1Q applies an extra field to the layer to header called
an 802.1Q tag.
Sometimes they just shorten it as a .1Q tag.
So if were actually to look at what this looks like,
if this was my IP packet here,
so from the perspective of ethernet that's just the data.
And we know that ethernet as a trailer, we call it an FCS
to the end of it.
And then here is my ethernet header at the front end.
Review question: very first field of an ethernet header,
what do we call that field?
That is the preamble.
I'll just put PRE. That's the preamble.
What follows the preamble?
That is the destination MAC.
What follows the destination MAC?
That is the source MAC.
Now, in a regular ethernet frame, what typically follows
the source MAC?
That would be the type code, the type field.
So there would be a number that we would put in here
if this is IP version 4.
There would be a number, a different number we would put
here if it's IP version 6.
well, if this ethernet frame is going across a VLAN Trunk,
and it has to be identified as belonging to
a particular VLAN,
we actually put our tag right here.
So the type field actually contains the tag.
So now here we have a special number, a type number
that says "This is 802.1Q"
So instead of the type field saying "Oh I'm carrying IPv4,
or I'm carrying IPv6," there's actually another number,
a reserve number that says "This is a .1Q tag."
Then there's a couple of other fields in here that we
don't really care about all that much, and then here
is where we put the VLAN.
So if this frame belongs to VLAN 55, you would see
the number 55 in here.
If it belongs to VLAN 6, you would see the number 6 in here.
If I just left it that way, I would be doing you
a disservice because I'd be letting you think,
"Okay, every frame that goes across the VLAN trunk has
a special tag that actually indicates the number
of the VLAN."
And that is true 99% of the time.
But take a look at the second bullet here.
It says all traffic except the native VLAN is inserted
with an 802.1Q tag.
By default, the native VLAN is VLAN 1.
Which means, that when, if I'm a switch, and let's say
I just got a frame on VLAN 1 and I say okay I need
to send it to you, you're another switch, and we have
a 802.1Q tag between us
I'm sorry, we have an 802.1Q VLAN trunk between us,
well if I'm going to put a VLAN 1 frame on here, I'm not
going to tag it.
So when you receive it, it's just going to look like
any other ethernet frame.
It'll have some type code in there that says IPv4,
or maybe a type code that says IPv6, but it'll just look
like a normal ethernet frame to you.
Now if I receive a frame on VLAN 7, as an example,
then before I put on this wire, I'm going to modify
the type code to say this is 802.1Q and this frame
belongs to VLAN 7.
So when you get it, you'll actually see that tag,
and you'll explicitly know it belongs to VLAN 7.
So every frame I put in this VLAN trunk will have a tag
unless it belongs to the broadcast domain known as VLAN 1.
Those frames are untouched, they go across the trunk
in their native format.
They are untouched.
That's why we call it the native VLAN.
Now as with pretty much everything else, if you have
a desire to do so you can change the native VLAN
to something else.
But the main thing is that if we change it, you and I
both have to agree.
If I decide that okay the frames I put on this trunk are
going to be untagged, just regular frames that belong
to VLAN 99, you need to know that, you need to have that
configured, because, how else would you know?
Like, let's say that I kept that as a secret.
Let's say that on my switch I decide, okay, I'm not going
to use VLAN 1 as the native VLAN, I'm going to use
VLAN 99 as a native VLAN.
So whenever I get a frame here from VLAN 99, when I put on
this trunk, I'm going to leave it alone, I'm not going to
tag it at all.
Well if you didn't know that, and you still thought that
VLAN 1 was the native VLAN, once you receive that plain
old ethernet frame without a tag, what broadcast domain
do you think you would assume it belongs to?
You would assume it belongs to VLAN 1 because you didn't
know what I was thinking, you didn't know what I configured.
That's why if you change the native VLAN on one side
of the trunk, you have to make sure it matches on
the other side of the trunk.
If it doesn't, like in that example where I think VLAN 99
is the native VLAN; you think VLAN 1 is the native VLAN,
guess what's going to happen?
Here comes in the broadcast on VLAN 99.
I put on that trunk untagged, regular ethernet frame,
and guess what, when it comes to you, you dump that
broadcast into VLAN 1.
Because you didn't know it came from VLAN 99.
So here's a broadcast that started in VLAN 99, and on your
side is now being dumped into VLAN 1.
That is a bad situation.
So that is why the native VLAN has to match.
And in just a second, one of the reasons why I created
this whole thing in GNS3, is because like I said in some of
the earlier videos, GNS3 has Wireshark built into it,
so we'll actually do a packet capture of some packets going
across the trunk so I can show you what that tag
actually looks like.
So 802.1Q as you can see just by the fact it was created
by the IEEE is a standard VLAN trunking.
This is not a CISCO-proprietary method.
So any switch should be able to suport 802.1Q trunking.
And we've talked about all this.
If you want to change the native VLAN, it is
an interface command.
So you would go into the interface that's your trunk,
whatever interface fast ethernet 0/7 or whatever it is,
and then you'd say switchport trunk navtive VLAN 99,
like in my example.
And both of us would have that in these interfaces that
were connected to each other.
Okay, so the simplest way to configure trunking is to
go into the interface.
And then say switchport trunk encapsulation dot1q.
Now you might be wondering, "Well, why do I need that?"
If 802.1Q is the way of adding tags, why do I
have to specify that?
The reason for that is CISCO a while ago, many many years
ago actually came up with this idea of trunking before
the IEEE did.
And they had their own proprietary way of
doing trunking called ISL.
It stood for Inter-Switch Link, ISL.
And the IEEE came up with, later on, 802.1Q.
So there's some CISCO switches out there today,
still quite a few of them, that support either ISL or 802.1Q
And so if you're on a switch like that, you have to specify
this command to let it know, I want you to do the IEEE way
of doing 802.1Q.
Now if you're on a switch that does not support that command
let's say you're on a switch and you type in
switchport trunk encapsulation ? and it says "unrecognized,"
well then you don't have to worry about it.
That is a switch that is only doing 802.1Q.
It doesn't even do ISL, so it's not even
giving you that command.
But it's just, sort of like I've been saying, there's
certain things you should do in network, and it's just like
a knee-jerk reaction, like write memory.
Every time I make a change to my configuration write memory,
save it, just get in the habit of doing that.
Going on to an interface and before you leave it,
doing no shutdown, just doing that by habit.
You should do this also, whenever configuring a trunk
just by habit you should type in
switchpot trunk encapsulation dot1q
If it doesn't recognize the command, nothing lost,
no worries, it's just a good habit to get into.
But then we have to change the mode.
Here we type switchport mode trunk.
And now that makes sure that this is operating
as a VLAN trunk.
Probably should do no shutdown, that's not in the slide here
but once again, just as a habit, you should type no shutdown
before you leave the interface.
And there's a couple of ways that we can verify trunking.
Show VLAN actually doesn't show you if an interface
is a trunk, it just shows you what VLANs you've got.
We looked at that in the previous video.
The command that I use the most often to see, do I have
any interfaces that are trunking and what interfaces
are they, is show interface trunk.
That's a command I use a lot.
You can also use show interface status
or show interface switchport.
(quick, light tones)