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.