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.