Well, this is a story that's as old as time.
In fact, you've probably potentially heard me or somebody else tell this story,
which
is that Cisco, seeing a problem in the networking world, said, "Hey, we've got
a great solution
for this.
We're going to create a solution for this."
And then eventually the rest of the industry says, "Hey, we need that too."
And they create a version that everybody can use, not just Cisco.
And in most cases, the Cisco version kind of gets quietly retired or sunset. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in most cases, the Cisco version kind of gets quietly retired or sunset.
In other cases, sometimes Cisco keeps that technology alive alongside the
industry standard.
What am I talking about here?
Well, what I'm talking about is the trunking world.
We're all used to hearing about this 802.1Q trunking.
And anytime we see this, 802.something, we're usually talking about the IEEE.
The IEEE is a standards-based organization.
They create standards and those standards can be used by anybody, whether it's
Cisco
or one of Cisco's competitors.
Meanwhile, Cisco likes to create their own technologies that only usually they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, Cisco likes to create their own technologies that only usually they
can use.
That's not always the case.
Sometimes they do open it up for everybody else to use.
But even in those cases, if you're Cisco's competitor, you really want to be
using Cisco's
stuff.
Usually you want to use industry standard for the sake of interoperability, as
well as
just not giving credit to your direct competitor.
So way back in the day, Cisco saw this problem that we had, which is eventually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So way back in the day, Cisco saw this problem that we had, which is eventually
solved by
trunking.
And we look at 802.1Q and say, oh, so that must be the solution, except there
was a solution
Cisco created first.
So let's look at this problem.
The problem is that we have now invented VLANs.
And I've got two VLANs, VLANs 10 and 20.
And I've got this other physical switch and some remote closet.
And I want some of the hosts attached here to be able to talk to hosts in VLAN
10 up
here.
And some of the hosts to be talking to VLAN 20 up here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And some of the hosts to be talking to VLAN 20 up here.
Why do my switches look like cats with whiskers?
Then we'll either way, we'd say, okay, well, that's great.
I want these hosts therefore to be in VLAN 10, these hosts over here to be in V
LAN 20.
And here lies the problem.
How do I connect these two switches together?
And so at first we'd just say, okay, well, I'll connect a connection here in V
LAN 10 and
a connection here in VLAN 20.
And that works.
That's perfectly fine until I have five or 10 VLANs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's perfectly fine until I have five or 10 VLANs.
And all of a sudden I need to have as many connections between these switches
as I have
VLANs.
And these switches only have 24 or 48 ports.
If I have to use 10 of them to connect to other switches, then that's going to
be problematic.
We see that this does not scale.
So the, again, solution was to create a way for us to connect these switches
that allows
one single connection to carry multiple VLANs.
This is the trunk. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is the trunk.
And the idea is that I can send a layer two frame across this trunk and it's
going to
include a tag that lets the other side know which VLAN this packet belongs to.
So I would include a tag for VLAN 10 and that way this receiving device knows
to check
the cam table in VLAN 10 here as well as potentially if it's a broadcast packet
, I know which ports
to send it out.
So that's great and all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's great and all.
On paper this is looking good, but how do we decide the technical
specifications of
the trunk and what does this tag look like and so on and so forth.
And so this led Cisco, not the industry, but Cisco to create a technology known
as Inner,
Switch, Link, or ISL.
This was the original trunking standard.
Well, I shouldn't use the word standard.
It was the original trunking technology.
It was created by Cisco and as a result it was only available on Cisco devices. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It was created by Cisco and as a result it was only available on Cisco devices.
Now it didn't take the industry long to say, okay, well we need that technology
but we
need everybody to be able to use it, not just Cisco.
And so that's where the IEEE created 802.1Q trunking and said, okay, we like
your ideas
but we're going to make them a little bit better.
So let's just have a very brief conversation about what ISL was.
Because ISL is kind of an interesting protocol.
Once again, it was Cisco proprietary, we know that it was only available on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Once again, it was Cisco proprietary, we know that it was only available on
Cisco switches.
But here's the fascinating thing.
It used true encapsulation, meaning that we were taking the Ethernet frame with
its header
and with its payload and with its CRC and we were encapsulating it in an ISL
header and
an ISL CRC.
In other words, we were almost treating this as if it was a tunnel interface.
And so the ISL header was actually 26 bytes and the CRC was an additional 4 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so the ISL header was actually 26 bytes and the CRC was an additional 4
bytes.
So we're adding 30 bytes to every single frame and sending it out.
That's a pretty large overhead.
But at the same time we actually did get one benefit compared to 802.1Q which
is that
we had 15 bits for the VLAN identifier.
That's a lot more VLAN IDs than the 12 bits that we get from 802.1Q. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's a lot more VLAN IDs than the 12 bits that we get from 802.1Q.
In fact, it's eight times the number of VLAN IDs that would have been available
using
ISL.
Furthermore, there was no such thing as a native VLAN.
So that concept didn't exist with ISL.
And the most important part about ISL is that Cisco really no longer supports
this.
So if we try to configure ISL on modern hardware like the Catalyst9 case, we're
going to find
that it's not available. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it's not available.
Although I will say that ISL was supported for a very long time.
If you have some maybe some Cisco devices that are 10 to 15 years old at this
point that
probably still support ISL, then you could configure it if you wanted to see it
in action.
So the industry then said, all right, this is great and all, but we're going to
create
our own version and we're not going to use encapsulation.
We're going to use this concept of a shim header or it's probably not even the
right
way of saying it in this case because we're going to modify the Ethernet header WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
way of saying it in this case because we're going to modify the Ethernet header
.
When we modify the Ethernet header, we're truly going to insert into the middle
of it.
So here's our frame and here's our payload and here's our Ethernet header and
the CRC
at the end.
Well we're going to insert four bytes that's going to allow us to carry a VLAN
ID.
Now this four bytes breaks down such that two of these bytes are really just a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now this four bytes breaks down such that two of these bytes are really just a
identifier.
It's hex zero, hex 8100.
And so it seems like a lot of wasted space to just be sitting there with the
first two
bytes over here.
But then when we get over to the next two bytes, this is where things get a
little more
interesting.
Specifically, we have 12 bits that are the VLAN identifier and an extra four
bits that
we use for quality of service.
So VLAN ID here and over here, this is where that class of service gets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So VLAN ID here and over here, this is where that class of service gets
leverage.
Now we recall class of service is only three bits.
And so we actually get three for the class of service, but then we get another
one and
this is used for something called the drop eligible indicator, the DEI.
But either way, this is all part of quality of service.
So we may recall during our quality of service conversations that if I don't
have a trunk,
then I can't carry COS bits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then I can't carry COS bits.
And the reason for that is simply if I'm sending out an Ethernet frame on an
access port, I
don't get any of these bits whatsoever.
I don't get the VLAN ID, but I also don't get the class of service bits.
And so that's why we have to make sure that we use trunks in order to carry
class of service
if we're going to rely on it for quality of service.
Now 802.1Q also introduced the concept of the native VLAN.
So the idea of the native VLAN is that we don't have to tag it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the idea of the native VLAN is that we don't have to tag it.
It is untagged.
The idea here was that it was considered a lot of overhead, especially at the
time, to carry
an extra four bytes per frame.
Is it that much percentage wise?
It's really not that critical.
And these days we don't really care that much about an extra four bytes.
But at the time that was the idea was, hey, we're kind of being a little bit
clever here.
We're getting rid of the overhead for maybe the VLAN that has the most traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're getting rid of the overhead for maybe the VLAN that has the most traffic.
We can declare it the native VLAN on a trunk.
We only get a single native VLAN because any untagged traffic will be assumed
to be part
of the native VLAN.
Now these days for number one, reasons with COS, we'd say, hey, we do want
class of service
even on the native VLAN.
So we want to carry that tag even in the cases of native VLANs.
But from a security perspective, we generally would rather not use native VLANs
either.
So in modern networks, we'd really rather disable the native VLAN and we'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in modern networks, we'd really rather disable the native VLAN and we'll
talk more
about that coming up.
But either way, 802.1Q did introduce the concept of the native VLAN as well.
Now one last consideration in all of this is we're talking about bits and bytes
.
And we might want to ask, hey, what about MTU?
Do we need to worry about this?
We may recall from MTU-based conversations that layer two MTU is usually set at
1500
bytes.
That's certainly the default. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's certainly the default.
And furthermore, layer two, ethernet, it doesn't support fragmentation.
And as a result, if we exceed the MTU, the packet is going to get dropped.
We can't just fragment it and send it on like we can if we break layer three MT
U, for example.
So what does trunking do for us?
I mean, we talked originally about adding 30 bytes for ISL, but even with 802.1
Q, we're
adding an extra four bytes.
Do we need to worry about changing MTU to 1504? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Do we need to worry about changing MTU to 1504?
And the answer is actually no, because layer two MTU is only going to map to
the payload.
We're talking about 1500 bytes.
We're talking about in here 1500 bytes, which means that neither the ethernet
header nor
the CRC count towards that 1500 bytes.
That works out really well for us because if the ethernet header lacks the VLAN
ID and
lacks the 802.1Q header, then fine, you know, it's not part of the MTU. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lacks the 802.1Q header, then fine, you know, it's not part of the MTU.
But even if it does include the header, it still doesn't include or it is not
counted
towards the MTU.
Now we might need to worry about it if this whole thing ends up getting encaps
ulated,
like we saw with VXLAN when I encapsulate this into VXLAN.
Now all of a sudden it does matter whether this inner header had those extra,
is it 14
bytes or is it 18 bytes?
Are we talking about the extra four or not?
At that point, we might need to worry about it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At that point, we might need to worry about it.
However, just in a standard layer two network, we fortunately don't have to
worry about MTU.
That problem isn't even a problem because the MTU only applies to the payload.
[BLANK_AUDIO]