I know when I first started out in IT I didn’t realize how important knowing the small things were. If you want to do anything more than a helpdesk position it will be a fact of life you will need to know how to use things like Wireshark to truly understand how to troubleshoot the problem instead of handing it up the food chain.

What is a Frame and what does it do?

The Frame has 5 main sections. These sections allow the Ethernet Frame to:

Sync Clocks on the talking hosts

Specifies Sender and Receiver of a package at layer 2

Detects errors by using CRC Checksum but does NOT correct them!

Allows the computer to send data of flexible length

As stated a frame is made up of several parts. I’ve tried graphically displaying these parts using a mind map.

So just to get you up to speed. This post will give the answers to my last post. In the last post we had PC1 ping PC4. ARP ran and helped PC1 and PC4 talk to each other.

The questions I left you with were:

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:

1.) Well neither PC2 nor PC5 have talked on the network. Because of this I would suspect that neither of the switches nor any of the other computers on the network know what their MAC address were. Because of this ARP would be needed and the process would be similar to what you saw for PC1 pinging PC4.

I’m not going to do the print out again but one thing to note is even though switch1 even though it knows the MAC address of PC1 it will always send out a broadcast out every port except for the port the request came in on.

Switch2 will also broadcast out the request to all ports except the one it came in on.

2.) Now that PC2 has pinged PC5 the switches will have a MAC table of PC1,PC2,PC4 and PC5 MAC addresses. Here’s the command below to verify.

If PC1 pinged PC5 should or shouldn’t it (PC1) need to send out an ARP request?

Answer: PC1 will still need to use ARP even if the switch knows where the MAC address is because what is ARP? ARP allows a host to find out the MAC address of another host by only knowing it’s IP address. The Host (PC1) sends out a broadcast saying “Who has this IP Address 192.168.1.5” because PC1 has never talked to PC5 yet. Switches work at layer 2 so they don’t have a clue what that means so they can’t help speed the process along.

So again there is an ARP broadcast and only PC5 will respond to it.

3.) What would happen if PC1 would ping PC6

Because of the last question this one should be a little bit more obvious. PC1 has never talked to PC6 yet. Again even if switches 1&2 knew about PC1 and PC6 address PC1 would still need to use ARP to find out PC6’s MAC address.

4.) What would happen if PC1 pinged PC3

Again PC1 would need to call on an ARP broadcast because it has never directly talked with PC3. ie. PC3 is not in the MAC table on host PC1. Much like 2 & 3, we’re going to need to call on our friend ARP to get PC1 to be able to talk directly to PC3.

If PC1 wanted to ping any other device it’s already talked to it would talk directly to it without the need of sending out an ARP broadcast!

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…

Crazy right?!?!

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?

Link Local Addresses are created automatically unless you force a device’s interface to have a specific address. They allow local communication. (ie They are are NOT route-able.)

I am assuming you’ve already checked out my post “Basics of an IPv6 Address”. One of the last things I was explaining was Link Local Addresses. Let’s first look at some Cisco IOS commands.

show ipv6 int brief – This will show the IPv6 addresses on the device. We are interested in the Link Local address

show int gig0/1 – This will display all kinds of things that relate to the device. We are interested in finding out the MAC address of the device.

I hope you can see that the MAC address and the Link Local address look very similar. When you see this you can automatically assume that it was created by “Extended Unique Identifier 64bit” (EUI-64). They look similar because the Link Local address is partially created from the Mac Address. So how is it automatically made? The rule is:

Flip the 7th bit. If it is zero change it to a one. If it is a one… flip it to a zero.

Put FFFE in the middle of the address.

When we look at a Mac address we notice it is a HEX number similar to an IPv6 Address. It is a 48bit address unlike a Interface Identifiers which are 64bit. Essentially it only has 3 groups of numbers and you need 4. To change a MAC address into an Interface Identifier it was agreed upon by the powers that be that we flip the 7th bit and add in a group to make it 64bit.

Go back up to the output from the IOS command above. The conversion of the Mac to Interface Identifier checks outs!

For most end user devices the automatically made modified EUI-64 address will be fine. Things like Servers and routers it might be better if you manually specified what their Link Local Address is. There are two ways of doing this:

You can change the Mac address to something that will give you something easier to work with like: 1111.1111.1111

You can force a Link Local Address.

To force a link local address you need to use the command:

ipv6 address fe80::1 link-local

Next post will be on two IPv6 protocols: IPv6 Neighbor Discovery Protocol and DAD