In this lesson,
we're going to discuss ethernet fundamentals.
Now, in the early computer networks, there were
so many different networking technologies out there,
and each one was competing for a piece of the market share.
Now, there wasn't much standardization
among these different types either,
and this led to a lot of problems.
I distinctly remember
back when I first started working on computer networks,
we had things like ethernet token ring, LocalTalk,
AppleTalk, NetBIOS, IPX and SPX,
frame relay, asynchronous transfer mode,
fiber distributed data interfaces, point-to-point protocols,
high-level data link control,
integrated service digital networks, and many, many others
that were all fighting to be the dominant market leader
in Layer 2.
Well, there was really one clear winner
in these Layer 2 wars,
and it was the one that we use most often today,
which is known as ethernet.
Now, ethernet really is the number one protocol
that we're going to use for Layer 2 communications
in most of our local area networks.
So, let's spend a little time together
focusing specifically on ethernet,
because it really is that important.
Truthfully, I can tell you with confidence
that if you don't understand ethernet,
you really don't understand
the way modern local area networks operate today.
Now, ethernet has been with us a very long time.
Originally, it was run over coaxial cables
using BNC connectors and vampire taps,
and these were called 10Base2 and 10Base5 ethernet networks,
also named thin net and thick net
because of the relative size of those coaxial cables.
Now, the great thing about these networks
is they could cover a pretty long distance
of up to 200 meters or up to 500 meters,
depending on if it was a 10Base2 or 10Base5 network.
Now for the network plus exam these days,
you do not need to memorize
anything about 10Base2 or 10Base5 networks,
because they are so old and antiquated
that you're likely never going to run into them
out in the real world.
The only reason I'm even talking about them right now
is because that when they were first used,
ethernet was being introduced
into the computer networks back in the 1980s,
and this was the type of networks we ran these things on.
Now, over time, we migrated
to something known as 10Base-T ethernet.
This allowed up to 10 megabits per second
of data transferring your network
and it can be run over a twisted pair of cable
known as a category 3 or CAT 3 cable.
These twisted pair of cables
could be unshielded or shielded,
and they were cheaper and easier to use
than that older 10Base2 and 10Base5 coaxial cable networks.
The only real disadvantage
to using these new 10Base-T networks
was that they could only cover a distance
of up to a hundred meters
before they needed to have their signal repeated
by a hub or a switch.
Now, I know that 10 megabits per second these days
does not sound like a lot, but back in the 1980s,
this was super, super fast.
After all, a dial up modem back in those days
was lucky to reach speeds of 300 bits per second.
So, this internal network speed of 10 megabits per second
is actually 10,000 bits per second,
and this was lightning fast to those users.
Now, the big question we had
when it came to these network devices,
especially when they start operating at these faster speeds,
is how are they going to be able to connect to the network
and then communicate on them.
Now, this is really one of the core questions
that ethernet had to answer.
Should their network access be deterministic
or should it be contention-based?
Now, a deterministic network
means that the network access
should be very organized and orderly.
Some of the competing technologies, like token rig networks,
use a deterministic style of network access.
If a device wants to transmit data on the network,
that device had to wait its turn
until some sort of electronic token was given to it
to signify it was that device's turn to transmit data
over the network.
To explain how this works, let's pretend
that we're all sitting in a classroom together.
In this room is you and me
and maybe 20 or 30 other students
all sitting in this classroom.
Now, if everybody started talking at the same time,
nobody could be heard or understood.
Instead, we'd have a bunch of collisions
as everyone tries to talk over each other
and it just sounds like a jumbled mess.
So instead, we need to create
some sort of deterministic system
to determine who's going to speak at any given time.
So whenever I'm teaching in a classroom,
I always say to my students,
"You have to raise your hand
and then when I call on you,
you're then going to be able to talk."
That is a deterministic method of accessing the network
or in our case, the shared environment in the classroom.
Now, since I was the instructor,
I was the one who determined who got to talk and when.
When I called on a student,
they were given this virtual token, this permission,
so they can then speak until that virtual token
was given back by the student
or by me taking back the virtual token
and speaking up myself, because I'm the instructor
and I can speak whenever I want
and I get to determine who gets to talk and for how long.
Now, if you use a token-ring network,
that is essentially how they operated.
Now, the great thing about this
is there are no collisions or in my classroom example,
there's no chance that other students
are going to talk over each other,
because everyone knows they have to wait their turn
until the instructor calls on them
and then they can transmit their message.
Now, alternatively, a network can also use
what's known as a contention-based system
to determine who gets to access and communicate
on the network at a given time.
Now, a contention-based network
tends to be very chaotic in nature.
Unlike my classroom example,
which was very deterministic
and the instructor got to tell everybody who could talk
and for how long, contention-based model
is more like when you go to a local bar or a pub
with your friends on a Friday night.
Maybe you're hanging out with five of your friends
and you're all having some drinks.
Now, normally people know how to interact
in these situations and carry on a conversation, right?
There isn't somebody in your group saying,
"Hold on, Alex, it's Jasmine's turn to speak,"
or, "Okay, Barbara, you've had your 90 seconds.
Now, it's Jamario's turn to talk."
I don't know about you, but if I had a friend
that tried to moderate our conversations like that,
I probably wouldn't enjoy hanging out with them very much,
and I probably wouldn't be going to next week's meetup
at the pub either.
Instead, when you're hanging out with your friends,
you just naturally take turns talking.
Each of us talks more or less
because it takes more or less time to tell our stories,
and so the flow of conversation naturally just happens.
Now, this is the real world example
of how contention-based discussions work.
Essentially, you're going to be sitting there
and whenever you hear a gap in the conversation,
you know it's going to be okay for you to speak
or to transmit your message.
If somebody else is speaking,
You're just going to stop and listen
until you find an appropriate time for you to transmit
or say whatever it is you wanted to add
to that particular conversation.
Now, the problem with using
a contention-based method like this
is that you can start having collisions
where people start talking over each other.
I know in the past
when I've been hanging out with my friends,
I may hear a gap in the conversation
and begin to start speaking, and at the same time,
one of my other friends starts talking as well.
This creates a collision,
because both of us speak at the same time
and nobody could be listening or understanding
what either of us was saying.
So what I usually do is I will pause,
let my friend continue their story,
and then I'll wait for the next gap in the conversation
to try talking again.
Now, because of this natural way of having a conversation
can lead to some people talking over each other,
some of your friends taking up more time than others,
and other issues like this,
contention-based models can become pretty chaotic.
Oddly enough though, this is exactly how an ethernet network
is going to work, because ethernet
is a contention-based networking protocol.
Now, you may be wondering why would they choose
a contention-based network over a deterministic one?
Why we have all that chaos added?
Well, the reason is because contention-based networks
actually have much lower overhead,
because you don't need to pass around that electronic token
and they can then make better use
of the full bandwidth in the network
because anybody can talk at any given time.
Now, I know this may seem odd,
but this is actually a really good thing.
You see when you're dealing
with a traditional deterministic network,
you might split up the communications into chunks of time
and then give each person an assigned time slot to transmit.
For example, if we have eight devices on our network,
we can say that everybody is going to get
an equal amount of time to communicate
of one eighth of one second.
That way they'll talk for one eighth of a second
and pass the token to the next network device,
and then they'll communicate for one eighth of a second,
and we'll continue to do this.
So out of every one second,
you're only going to be able to transmit
one eighth of that second.
Now, if you're using a 10 megabit per second network,
you are only going to be able to transmit
a single device 1.25 megabits
during their portion of that second.
Effectively, if you have eight clients,
you just cut the network speed down by a factor of eight
because most of the time, all of these devices
don't have something they need to communicate.
Think about it, if you and your friends
were sitting around the table at the pub
and I said that each of you had to take turns
and you can only speak for one minute at a time.
Now, some of your friends could fill up that one minute
during their term and still not get out their whole story,
but others, they might tell a quick one line joke
that only took 15 seconds
and now the rest of us are sitting there
and waiting and listening to silence for 45 seconds,
until it's the next person's turn to talk.
For this reason, deterministic models
are going to waste a lot of resources.
So when they designed ethernet,
they chose to maximize the efficiency of the network
by allowing anyone to use all the bandwidth in the network
at any time for as long as they need.
Now, if any network device can transmit
at any time of the network,
how are we going to prevent collisions?
Well, the way ethernet approaches this
is by using something known as CSMA/CD,
and this stands for carrier sense multiple access
with collision detection.
Now, carrier sense multiple access with collision detection
is going to work just like when you're sitting at the pub
on a Friday night with your friends.
You're first going to listen
and wait until you hear that gap in the conversation,
and then you'll start to talk.
If two people spoke at the same time, you simply say,
"Oh, I'm sorry,"
and then you pause for a random amount of time
and then try to speak again
if there's another gap in the conversation.
Well, this is the exact same idea here
inside of ethernet when we're using CSMA/CD.
So, let's break down CSMA/CD into each of its parts.
First, we have CS, which means that our ethernet devices
must be able to do carrier sensing,
and that means they can listen to the network
to determine if there's already a signal being transmitted
over that network at that time.
Carrier is just a fancy word in electronics
that is referring to the signal that carries information
or data over a given media like a cable, a fiber,
or a radio frequency wave.
Now, if there's a gap in the communication,
then we can move into the MA part of CSMA/CD.
MA is going to stand for multiple access, and all this means
is that there are going to be many different devices
that all have the ability to access,
listen for, or transmit on that same network
at a given time.
So, ethernet is going to have
a lot of devices connected to the network
and they're all going to be listening before they speak.
This is the CSMA part of CSMA/CD.
Now, this brings us to the last part,
which is CD or collision detection.
Since all of these network devices
are listening on the network,
if they detect a collision has occurred
when they're transmitting something,
then those two devices that we're talking over each other
are going to have to decide who's going to transmit their data now
and who's going to have to wait and then retransmit.
To simplify this process,
ethernet is going to use a pretty clever method
to determine who gets to transmit first.
Now, whenever there's a collision detected,
both of those ethernet devices
are going to stop transmitting immediately
and they're going to pick a random number.
Then, they're going to wait that amount of milliseconds
before they try to retransmit their message again.
So if you and your friend both speak at the same time
when you're sitting around the table at the pub,
you might have a rule that you both need to pick
a rate of number, count up to that number in your head,
and then if nobody is speaking,
you can then transmit your message.
This is exactly what an ethernet device does
when they detect a collision.
They'll stop transmitting, they pick a random number,
and then they start counting.
This is officially known as a random back off timer,
and this allows the two devices
to attempt to retransmit again when their timer hits zero.
I want you to think about it this way.
Have you ever been walking down the hallway at work
and somebody's coming from the other direction,
and it's a small hallway.
And as you walk up to each other,
you kind of do that little dance of I'll go left,
you go right, I'll go right, you go left,
and neither of you is actually getting out of the way.
Now in this case, if neither of you say anything,
you're just going to try to figure it out
by kind of doing this dance back and forth,
and that's not really that efficient.
Well, if this has ever happened to you,
you are smack dab in the middle of a CSMA/CD collision.
So, what should you do to be more effective
when this happens?
Well, I'll tell you what I do.
Whenever I do it, I do exactly what ethernet does.
I literally will stop in the middle of the hallway
where I am and I'll count in my head to two or three.
Now, if the person walks around me
during those two or three seconds, great, I will let them,
and then I'll continue to walk down the hall
once they pass me.
But if they don't move during that two to three seconds,
I will walk around them
and then continue down the hallway myself.
This is really CSMA/CD at work,
and it effectively ends that side to side dance
that can go on during a collision in the hallway.
So, let's take a quick look at
what this looks like in an ethernet network.
In this example, I have six devices on the network
and they're using a bust apology
just to make it easier for you to see.
With ethernet, we could use a star, a bus, a ring,
or any topology you want.
It really doesn't matter.
But for this illustration
and to fit everything on the screen,
I'm just going to go ahead and use a bus.
So if device number 4 wants to talk
to device number 5, they can communicate
over this network segment
and there's not going to be any problems
because nobody else is talking right now.
Then if device number 2 wants to talk
to device number 1,
they can see through carrier sensing
that the line is clear,
and so device number 2 will transmit
and device number 1 will receive that data,
and there'll be no issues either.
But what happens if two devices
try to talk at the same time,
like device number 3 and device number 5?
First, they listen to the carrier.
If they don't see anybody else talking already,
that means they can both try to talk.
And if they do that simultaneously,
that transmitted data is going to cause a collision,
and we will get this big red X on our screen.
Now, a collision is detected,
so now that we have a collision detected,
device 3, and device 5
are both going to pick a random back off timer.
In the case of device 3,
it's going to choose to wait 30 milliseconds.
In the case of device 5, it chooses 150 milliseconds.
Both of these are chosen at random.
So, what's going to happen next?
Well, 30 milliseconds goes by,
device number 3 is going to listen to the carrier
and it doesn't detect anybody else transmitting,
so it starts transmitting.
At the same time, device number 5 is still going to be waiting
because we've only had 30 milliseconds pass by
and it chose to wait 150 milliseconds,
so it still has to wait another 120 milliseconds
on its back off timer before it checks the carrier
to see if anybody's communicating well.
Now, the device number 5 is going to be waiting.
It waits until the end of the 150 milliseconds.
Once that timer hits zero,
it's going to listen to the carrier again,
and if it hears somebody transmitting,
which in this case device number 3 is still transmitting,
it can wait until it finds a new open spot
in the conversation, which will occur
when device number three is done transmitting,
which in this case
is about another 180 milliseconds from now.
Now, whenever device number three is done communicating
and the carrier seems clear for transmission,
device number 5 will transmit its message
and hopefully it will get through this time
without a collision.
Now, if during this time somebody else happens
to transmit the same time as one of these devices,
we're going to have another collision,
and both of these devices
will choose a random back off time again to wait,
and then the cycle repeats until everybody
has transmitted everything they want to send.
Now, if this seems like a bad way of doing things,
because as our networks get busier and busier
and have more and more clients,
we would end up having more collisions,
well, you would be 100% accurate and correct.
The more devices you have communicating
on a single network segment,
the more collisions you are going to have.
Each area of the network that shares a single segment
is what we call a collision domain.
In the example I showed you of this bus network,
we have six devices all sharing a single bus cable
and this makes up our collision domain.
With ethernet, anytime you have devices on the same cable,
or if they're connected to a hub,
they're all going to be sharing the same collision domain.
Because of the shared collision domain,
all of the devices will need to operate in half duplex mode,
so they can either listen or talk,
but they can't do both at the same time.
If a device talks and listens at the same time,
they're simply going to hear themself
and think that some other device
is on the network transmitting,
and so they're not going to send their message.
So, they can't operate in full duplex
when you're using a hub or a shared network segment
or simply, they'll end up being way too many collisions.
For this reason, we need to keep our collision domain small
inside of our networks.
If you have a very large collision domain,
there's a very high possibility
that collisions are going to occur
and each time a collision occurs,
this requires the data to be remitted
after Waiting a random back off timer to finish.
This will slow down the entire network segment
and actually slow down your entire network
to a much lower bandwidth than what you should be getting.
If you have a hub with four devices,
this probably won't be a major issue for you.
But if you're using a 24 or 48 port hub,
these collisions will bring your network
to a screeching halt.
Think about it this way, if we're going to the pub
with a group of four people,
we can make that conversation work fairly naturally
without having too many collisions.
But if we have 20 or 25 people,
we're going to have entirely too many collisions
and it simply won't work.
So, we're going to need to break our larger group
into smaller groups.
If we're going to the pub this weekend,
we may do this by breaking up our group of 20 to 25 friends
into groups of four or five people,
and then sit them each at different tables.
This breaks down our large single collision domain
of 20 to 25 people
into five or six smaller collision domains
of four to five people each.
In our networks, the way we break down our collision domains
is by using ethernet switches or bridges.
This drastically will increase
the scalability of our networks
by creating a lot of collision domains.
And that's a really good thing
because when you look at a switch,
every single switch port
is considered to be its own collision domain.
And so here, you can see with my switch in the center,
I have four collision domains,
one in between each computer and the switch itself.
Now, if I was using a hub, all four devices
and the hub itself are all going to share
a single collision domain,
and this will end up causing a lot more problems for us
as these hubs get larger in size.
So by simply replacing a hub with a switch,
I can actually increase the speed of my network
because nobody else is talking on that switch port
except for the devices I cable to it,
and therefore the switch port can now operate
in full duplex mode.
After all, if there's only my device
and the switch on this network segment,
there is no chance a collision.
It's like if I was sitting in a room all by myself,
I can talk all I want and I'm never going to have a collision
because nobody else is there to talk with me.
So when you're using a switch,
you can operate in full duplex mode
because all of your devices will not have to listen
before they transmit because they know
they have a full-time dedicated channel between themselves,
the device, and the switch they're communicating to.
This allows us to transmit data faster
and to get more bandwidth out of our connections.
Now, I know this was a long lesson,
but the key takeaway here
is that ethernet is our preferred Layer 2 protocol
that's going to be used in our modern networks
for most of our use cases.
Also, if you're using ethernet,
you should be using switches instead of hubs
because each switch port
is going to be its own collision domain
and can operate in full duplex mode
instead of half duplex mode like a hub has to
because of the way carrier sets multiple access,
collision detection systems are going to work.