I wish I had something like this when I first started networking. Some background on the test network.
- There are six computers
- Each computer is named PC1->PC6
- Each PC has a MAC address that is reflective of it’s name 0020.1111.1111 for PC1->0020.6666.6666 for PC6
- Each PC has a IP address that is reflective of it’s name 192.168.1.1 for PC1 –> 192.168.1.6 for PC6
- Each Port a pc is plugged into is reflective of it’s name. Port 1 for PC1 –> Port 6 for PC6
- Both switches are connected to each other on Gig1/1
I have set this up so when you are looking at commands later on you can easily see where the packets came from and where they are going.
First task is on PC1 we are going to ping PC4. What will happen?
On PC1 type “ping 192.168.1.4” at the command prompt.
The computer realizes it has absolutely no idea who 192.168.1.4 is because it doesn’t know it’s MAC address. ICMP is put on hold and the computer sends out an ARP request to try and figure out where 192.168.1.4 is.
PC1 sends the frame to switch1. Because this is the first time switch1 has talked with PC1 switch one looks at MAC source address and learns PC1’s MAC address which is 0020.1111.1111
Switch1 will broadcast out on all ports except the port the frame came in on. That means PC2, PC3 and Switch2 will all receive the exact same frame. PC2 and PC3 will know right away this packet is not for them.
Switch2 will broadcast out the packet very similarly like switch1 did. PC5 and PC6 know right away it’s not for them. PC4 looks at the frame and says yes… I am 192.168.1.4. My MAC address is 0020.4444.4444. It does so by sending an ARP reply message back to PC1.
PC4 sends the reply back to switch2.
switch2 sends the reply back to switch1. Switch1 looks at the frame header and sees that there is a new MAC address of 0020.4444.4444 in the source. Any time 0020.4444.4444 is needed it will just send the frame directly out Gig1/1.
switch1 knows what MAC address PC1 has so it sends the package directly to PC1. PC2 and PC3 aren’t bothered like they were when this whole process originally started.
Something to note… A bunch of stuff has happened. If we go back to the command prompt… It hasn’t changed a bit…
Now that PC1 knows what MAC address PC4 has it can now do what it wanted to do… ie. ping PC4 using ICMP. PC1 will send an ICMP packet (ping request) to switch1 with a destination address of 192.168.1.4
switch1 knows that 0020.4444.4444 is somewhere out Gig1/1 so it directly sends the frame to switch2.
Because switch2 already knows the MAC address of PC4 0020.4444.4444 in its switching table it can forward the ICMP packet to PC4.
PC4 will now send a reply back to PC1. To do this it will send the packet directly to switch2
Switch2 will send the packet directly to switch1
Switch1 will look at the header and realize it needs to go to PC1 and will forward the packet onto PC1.
It’s at this point the command prompt will change a bit. It will now look like this:
In the emulator it says ALL requests took a total of 0.012sec.
For the next 3 ping requests we don’t have to worry about ARP at all. All devices know how to get to each other. As long as the network is stable you would expect the next 3 results to be similar. Notice how the first ping took a little longer and the next 3 are a bit shorter ie6ms? Because ARP isn’t needed for the second, third and forth ping the requests are only 6ms.
Now that you know how about how a switch works let’s ask some more questions…
1.) What would happen if PC2 were to ping PC5? Would ARP be needed? If so what devices would get the ARP request.
2.) What would happen after PC2 pinged PC5 and PC1 would ping PC5? Would ARP be needed? If so what devices would get the ARP request?
3.) What would happen after PC1 pinged PC5 and PC1 pinged PC6? Would ARP be needed? If so what devices would get the ARP request?
4.) Would would happen after PC1 pinged PC6 and PC1 pinged PC3? Would ARP be needed? If so what devices would get the ARP request?
Answers to these questions can be found here: http://jaredheinrichs.com/answers-to-how-do-switches-work-by-tracing-packet-flow-post.html