Network Switching Overview - N10-008 CompTIA Network+ : 2.3

The role of a switch
is to forward traffic

based on the
destination MAC address

inside of an ethernet frame.

This means the switch needs to
keep an ongoing and active list

of all of the devices
it happens to know about

based on the MAC address
of those devices.

The switch builds this list
by looking at inbound traffic

and examining the
source MAC address,

and tying that source MAC address

to a specific physical interface.

And for switches
that are configured

with spanning tree
protocol, or STP,

they're also responsible for
ensuring that a loop does not

occur on the switch network.

The process of sending traffic
through a switch network

is the same for every ethernet frame.

Let's take this
scenario where Sam,

and you can see the MAC
address for Sam's device,

is sending information
to the SGC server,

and you can see the SGC server's
MAC address is 1000:5555:5555.

We have a switch in the
middle, and all of our devices

are plugged into the switch,
including Sam and the SGC server.

Inside of the switch
is a MAC address table.

It lists all the MAC
addresses and the interfaces

where those addresses are connected.

When Sam sends traffic to the
switch with the destination MAC

address of
1000:5555:5555, the switch

looks up that address in its table,

and if one matches one of the
entries inside of that table,

it identifies the output
interface for that traffic

and sends it down that
interface to the server

that has that MAC address.

If you have multiple switches,
it's exactly the same process,

except it occurs twice,
once on the first switch

and once on the second.

You can see this is the
same configuration where

Sam is communicating
to the SGC server,

but there is a switch A
on one side of the network,

and a switch B on the other.

Switch A has a MAC address table
specific to the devices plugged

into Switch A, and Switch B
has a completely different

and unique, MAC address table.

Sam is going to send traffic
again to the SGC server.

It knows that it's sending this traffic
to MAC address 1000:5555:5555.

As that traffic hits Switch A, Switch A

refers to its own MAC address table

and knows that that particular
MAC address is located

on an interface that is
a gigabit 0/2 interface,

and so it sends that
traffic out that interface

to the next switch.

On that switch, the
same lookup process

occurs, where Switch B will
examine the destination

MAC address, determine that
that MAC address is associated

with the interface fast ethernet 0/5,

and sends that traffic down that
interface to the destination device.

You can see that building
that MAC address table

is extremely important.

If we didn't have the MAC
address table, the switch

would not know where to send that traffic.

In order to build
that table, the switch

is going to examine
all incoming traffic

and make a note of the
source MAC address.

It will then associate
that source MAC address

to a specific interface
on the switch.

So let's take a scenario where
we've just powered up a switch,

it has nothing in the
MAC address table,

and we're going to send
information from Sam's computer

to the SGC server.

Sam's going to send that
traffic to the switch,

the switch is going to examine
the source MAC address,

and in the case of Sam's
device, that's 1000:1111:1111.

It will then put that MAC
address into the MAC address

table, and it will
identify the interface

where that information was received.
In this case, interface F0/1.

That information is then
sent on to the SGC server,

and then when the SGC server
responds to that communication,

it has a different
source MAC address,

and the process is repeated.
Except in this case,

the switch identifies
that MAC address is

coming from fast ethernet 0/5.

In that previous example, we
were sending information to the SGC

server, but the SGC
server's MAC address

was not yet in the switch.

If the switch does not have
an entry for that MAC address

in the table, then it
will send that information

to everyone on the network.

For example, we'll take Sam
sending this information

to the SGC server.

You can see in this case,
the MAC address table

has nothing inside
of it at the moment.

The MAC address table will be
updated with the source MAC

address because Sam did send
that information to the switch,

and it did associate that
with fast ethernet 0/1,

But we're sending this information

to a destination MAC
address that's not currently

listed in the switch's table.

In that case, it's going to now
send that traffic to everybody

on the network, and
effectively flood

that traffic to all of the
other interfaces on that switch.

If you're familiar with
the operation of a hub,

then you'll notice that this
is very similar to the way

a hub works normally.

But this traffic being
sent to every device

ensures that at least
the destination will

receive this particular frame.

And in this example, you can see
that the SGC server did indeed

receive that frame, and
when the SGC server responds

back to Sam with a response,
the source MAC address

will be identified by the switch.

That information will be added
to the MAC address table,

and the switch will no longer
need to flood the traffic

across all interfaces if communication
is occurring between Sam

and the SGC server again.

On an IPv4 network,
devices are able to obtain

the MAC address of a remote
device using the ARP protocol.

ARP stands for
Address Resolution Protocol.

ARP will query the network
for a specific IP address,

and that IP address will respond
back with its MAC address.

Your local computer keeps
a cache of all of the MAC

addresses that it currently knows.

If you wanted to look at
the ARP address table on

your local machine, you
can use the command arp-a.

Let's run the arp-a
command on my machine.

You can see that I have a number
of local devices on the 10.1.10 network.

You can see them all listed here.

There's also some other
devices on my local network,

including some APIPA addresses
and some multicast addresses.

Let's say that I want to
communicate to a switch

that I have on my network.

That switch's IP
address is 10.1.10.210,

and you can see in
my ARP address table,

I don't currently have
that address in the list.

So I'm going to perform a ping,
and I'm gonna ping 10.1.10.210,

and I'll get some responses back
from that particular device.

If I now look at my ARP
address table with an arp-a,

you will see that I have a
new entry for 10.1.10.210,

and you'll see that I have a MAC
address associated with that IP address.

When I performed that ping,
the first thing that occurred

was an ARP request
made to the network

to try to find that
particular device,

and I received an
ARP response, which

then allowed me to send traffic
to that device directly.

I captured the ARP
communication using Wireshark,

which is a packet analyzer, and
you can download and install

Wireshark on your own
machine to see not only ARPs,

but all of the network
traffic on your system.

The first frame that I'm
sending is from my device,

and it's sending it
out as a broadcast,

and the ARP itself is
requesting the MAC address

for who has 10.1.10.210.

You can see the
details of the ARP

that are located further
down in the detail.

You can see the
sender MAC address,

which is my Apple computer.

You can see my local IP
address, which is 10.1.10.249.

You can see the
target MAC address,

right now we don't know what
the MAC address is of the target,

so it's all zeros, and you can
see that I'm requesting the MAC

address for the device that has
the IP address of 10.1.10.210.

We very quickly get a response
from this device, which

happens to be a Cisco
switch, and the response

from the MAC address is
from the Cisco MAC address

with the sender's IP address,
which is 10.1.10.210,

and the target is the response back

to my Apple computer
and my local IP address.

You can see in the response
that it filled in the sender MAC address,

so instead of being all zeros,
I see this long MAC address

associated with this IP.

And if you remember
the IP address and MAC

address in my
local ARP cache, it

matches both of those that were
received by this ARP response.

That ARP process is what
we use an IP version

4 to be able to
identify a MAC address,

but we don't have
broadcasts in IPv6.

There's also a different
process for IPv6

to identify the MAC addresses of
devices on your local network.

In IPv6, we use in NDP,
which is Neighbor Discovery

Protocol, using multicast,
specifically with ICMPv6.

This replaces the ARP function
that we would commonly

see in IPv4 with
this Neighbor MAC Discovery.

This can also be
used in conjunction

with SLAAC, which is Stateless
Address Autoconfiguration,

which allows the system to
automatically configure itself

with an IP address without
using a DHCP server.

Neighbor Discovery Protocol is also

used to identify any
duplicate addresses using DAD,

or Duplicate Address Detection.

If you wanted to see
the conversation that

takes place in IPv6,
instead of using ARP,

we send a neighbor solicitation,
or NS, on a multicast address,

and that is the IPv6 multicast that's
used for this neighbor solicitation frame.

The response is sent back from
the other side with a neighbor

advertisement, or NA, and that NA

includes the MAC address
of that local device.

Although the protocols and the
method is slightly different,

you can see that the process is very
similar to the one that occurs in IPv4.

Not only are we sending
data over ethernet networks,

we can also send power
over those networks

at the same time using
Power over Ethernet, or POE.

This allows us to connect
devices such as access points,

voiceover IP phones,
and other devices

by simply plugging in
an ethernet connection.

You don't have to then
plug in a separate power

connection for that device.

That power is coming
from either the switch,

or another device that's
connected into the network.

If it's coming from the switch,
we call that an Endspan,

or if it's coming from an injector,
like the one you see here,

which sits in the middle of an
existing ethernet connection,

we refer to that as a Midspan.

If your ethernet network
is a 10 or 100 megabit

per second connection, then you
have some extra wires inside

of that cable that you
could use for power.

We refer to that as Mode
B power over ethernet,

where you're sending
power on the spare pairs.

But if you're using
gigabit connections,

you're using all of those wires
for your gigabit ethernet data.

And in those cases,
we're using Mode A,

where we're sending power
and data over the same wire.

You'll find there are a
number of different power

over ethernet standards,
and these standards

are being added to and
changed all the time.

Two very common standards are
the IEEE 802.3af from 2003.

We refer to that as the
original POE standard, which

provides 15.4 watts of
direct current power,

with a maximum current
of 350 milliamps.

An update to that standard
is what we call POE+.

This was updated
with 802.3at in 2009.

This also has been incorporated
into the existing 802.3 ethernet standard.

This provides a bit more
power on the ethernet network,

25.5 watts of DC power, with a
maximum current of 600 milliamps.

There are other power
over ethernet standards,

and these are being
updated all the time,

so make sure you check with the
ethernet standards from IEEE

to know exactly what options
may be available for you.