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 addresses 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 were 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 in to switch, 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
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 time 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 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 on a 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 IP version 4 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, voice over 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.