Tracing packet flow between a Hub and Switch

A few days ago a blogged about what would happen when you had 6 computer separated by two switches. If you didn’t see it please check it out here:

How do switches work by tracing packet flow

Today we are going to see how do switches and hubs interact with each other by tracing packet flow. Here’s the network we are going to be playing with today.

Like my previous article PC1 will have an IP address of 192.168.1.1 — It will be plugged into PORT 1 of the closest networking device and have a mac address with the last 8 characters the same as the number of the PC like 1111.1111. PC2 will have an IP address of 192.168.1.2 — plugged into PORT 2 etc…

Like a Magician I am going to show you nothing is up my sleeve. In order to do this I need to show you the Mac address table on “SWITCH”

As you can see there the switch hasn’t learned any MAC addresses. Reading text books you might here things like “A switch can break up collision domains”. What the heck does that actually mean?

Well in order to understand it you need to know a bit on how Ethernet Works. When a computer on the network say PC1 wants to talk to another computer say PC4 it will always look to it’s own MAC address table. It will ask “Have I talked with host PC4 before?”. If it has it’s arp table will have that computer’s IP address and matching MAC address. If not that means the PC1 will need to use ARP to send out a broadcast message “FFFF:FFFF:FFFFF” and ask the computers if they have the IP address of 192.168.1.4 and if so, please send back their mac address.

What makes this layout a bit harder to understand than if it were just two switches is a HUB is a dumb device. All it does is forward incoming frames out every port but the port it came in on.

Ok. Let’s just get to work and see how the packets will flow:

Let’s start with the same scenario we just talked about. PC1 will Ping PC4. PC1 will try and ping 192.168.1.4 but will have to resort to ARP before it can send the ICMP request out on the line.

The ARP broadcast will be sent down the wire to the HUB.

Because the HUB is dumb it will need to forward the packet out all ports except the one it came from. PC2 and PC3 both know this packet is not for them.

SWITCH doesn’t know anything about PC1. Because the broadcast frame will have the host MAC address as .1111.1111 it will add this to it’s MAC Address list.

It will now forward the packet off to all ports except the port the frame came in on.

PC5 & PC6 reject the frame because it’s not for them. PC4 says… Hey… I have the address of 192.168.1.4. It sends back a reply making sure to set it’s MAC address as the originating address and puts PC1’s address in the destination field. Because PC4 now knows PC1’s MAC address he does not need to send an ARP request to figure it out. He will also add PC1’s MAC address in his MAC address table.

PC4 sends the reply back to SWITCH.

SWITCH will put PC4’s MAC address into it’s MAC address table so when the PC1 actually sends the ICMP ping request it will know how to resolve IP Address 192.168.1.4 down to the MAC address of: 0010.4444.44444

SWITCH will send the response back to HUB.

Again since HUB is dumb he has to send it out every port except the one it came in on. PC2 and PC3 will drop the frame. PC1 will now know how to send the ping request!

PC1 can now ping PC4 as directly as it can. The frame will be sent down to the Hub.

Similar to how the arp broadcast went PC2 and PC3 will get the same frame because the NUB just blurts out everything it hears on the ports the information didn’t come in on.

This is where the smarts of the switch come in. Because it knows what port the MAC address 0001.1111.1111 is it sends it to only that port. ie. PC5 and PC6 don’t get the frame like PC2 and PC3 did in the last step.