ARP (Address Resolution Protocol) explained

Hello Ananth

In a topology like the one you show in your post, MAC address learning on all of the ports for SW1 and SW2 will be the same. A switch will always populate its MAC address table with the source MAC addresses arriving on specific ports. This is also done on the ports connecting the two switches. And it is also important to note that this is done regardless of the port type. If SW1 and SW2 are connected via a trunk, MAC address learning will still occur on those ports.

So in essence, the MAC address table entries for the port on SW2 where SW1 connects, should have multiple MAC addresses, including all of the hosts connected to SW1.

Now concerning ARP, you are correct. ARP responses are unicast responses that contain the source MAC address of the responding host. That means that the switch will indeed learn about that MAC address and populate the MAC address table accordingly. So after an ARP exchange, a switch will know the MAC addresses of both hosts.

However, the lesson was written in this way to emphasize that these are two separate processes, independent from each other, but related. This is the reason why Rene emphasized that when a switch doesn’t have a particular MAC address in the MAC address table, any frame destined for that MAC address will be initially flooded.

Keep in mind that there are many cases where ARP is not sufficient to keep that MAC address table up to date. For example, a MAC table entry expires, by default, after 300 seconds (5 minutes). An ARP entry in a host expires after four hours, again by default. This means that hosts may send traffic to destination MAC addresses that have expired without needing to send an ARP request. In this case, the flooding of such frames is a necessary part of the process of communication.

I hope this has been helpful!

Laz

Hi Laz,

Thanks. Also one more question. Do we need to configure access ports and trunk ports exclusively on a live cisco switch?

Also if I use network simulator , seems no need to configure access and trunk ports . Is that correct?

Does switch have ARP table? Could you pls explain with ARP for the below data flow

Host A - Swich1 - Switch 2- Host B

Hello Ananth

By default, a Cisco switch had DTP enabled on all of its ports. Now this means that ports will become either access or trunk ports depending upon what is connected to the other end of that link. If it is a PC, it will be an access port. If it is a switch with a port configured as a trunk, then the port will also become a trunk. For more information about how DTP works, take a look at this lesson:

Now this is the case for physical switches, as well as for switches in simulators like Packet Tracer or emulators like CML or GNS3.

In any case, it’s always a good idea (best practice) to explicitly configure the ports as you want them. That way you avoid security risks that are associated with DTP, as described in the lesson above.

You may also find this lesson useful:

I hope this has been helpful!

Laz

Hi Laz,

Thanks.

Does switch have ARP table? Could you pls explain with ARP for the below data flow

Host A - Swich1 - Switch 2- Host B

Hello Ananth

Yes, all network devices that operate IP over an Ethernet network maintain an ARP table. But we must not confuse the ARP table with the MAC address table.

The ARP table maintains an IPv4 to MAC address mapping so that a device can correctly populate the destination MAC address field within the Ethernet frame when it is sending packets on the network. ARP is thus used when the host itself is the source of the packet.

The MAC address table maintains a MAC address to switchport mapping and exists only within switches. This is used for transient traffic (not sourced from the switch itself) so that the appropriate egress port will be chosen based on the destination MAC in the frame.

Now switches also maintain an ARP table, but only for traffic sourced from the switch. So if you ping from the CLI of the switch to a host, then the ARP table will indeed be used.

For more info, take a look at this NetworkLessons Note on ARP and its associated links.

I hope this has been helpful!

Laz

Concerning the ARP protocol , i would like to know if let’s say h1 doesn’t know the mac address of h2. How does it get it ? Is it by pinging h2 ?

Hello Fisnell

If H1 needs to send information to H2 and it doesn’t know the MAC address of H2, it will send an ARP request. The ARP request is sent to the multicast MAC address of FF:FF:FF:FF:FF:FF which means it goes to all hosts on the segment. That ARP request contains the destination IP address H1 wishes to reach. H2 will receive this broadcast ARP request, see that the IP address in the request is its own, and respond to H1 with an ARP reply containing its own MAC address.

H1 can now encapsulate that IP packet into an Ethernet frame with the appropriate destination MAC address to reach H2. A more detailed description of this process can be found in the following lesson:

I hope this has been helpful!

Laz

Hi, just after some clarity on ARP lookups. Take the following scenario…Host A wants to connect Host C via https e.g. access a webpage. Router B sits in the middle

**
Host A - internal LAN
Router B (perimeter/firewall) - gateway for Host A
Host C - on the public internet somewhere
**

If Host A does not have an ARP entry for Host C in its ARP table, which will happen:

i) Host A sends an ARP request to find the MAC address only for Router B, and Router B does an ARP lookup for Host C
ii) Host A sends an ARP request to find the MAC address for destination Host C - it does this directly from itself

Just trying to get clarity on ARP on trying to find a ARP lookup when devices are outside of the network, how this works and what role is played by who.

Thanks.

Hello Irfan

In your scenario, host A and host C are in different network segments, and are thus on different subnets. Remember that ARP is used to populate the destination address field of the Ethernet frame with the MAC address of the very next hop. That next hop may be the destination host, or it may be the local default gateway.

So when Host A sends an ARP request, it will first check to see if the IP address of Host C is on the same subnet. In your scenario, it is not, so then the ARP request will be for the MAC address of the configured default gateway, which is Router B. So for that particular communication, from Host A to Router B, the destination MAC address is that of Router B.

When Router B routes that packet and encapsulates it, it will send an ARP request on the subnet where Host C resides. Host C will respond, and Router B will place in the Ethernet header the destination MAC of Host C.

So ARP takes place for each “communication leg” requesting the MAC address of the very next hop, and not of the ultimate destination.

There are cases where a router may relay the MAC address of a particular host from one subnet to another, and that’s called Proxy ARP. For more information about that, take a look at this lesson:

I hope this has been helpful!

Laz

Hello,

I’d like to know how an ARP request between hosts that are physically located in two separate branch offices (so separated by a WAN link) but belong to the same VLAN gets delivered.

Topology:
Host A → Switch A → Router A → ISP → Router B → Switch B → Host B

Both host A and host B are in VLAN 99. When host A sends an ARP request for host B’s MAC address, that ARP request gets forwarded to Router A. Shouldn’t Router A filter/drop the frame (because routers separate broadcast domains, and an ARP request is a broadcast frame)? But aren’t there real-world topologies where the same VLAN is configured in different branch offices, meaning there is at least one router between the hosts that belong to the same VLAN? So that tells me this should work, but how?

Can someone please explain this to me?

Thanks, and have a nice weekend.
Attila

Hello Attila

It all depends upon what you mean when you say the two remote hosts “belong to the same VLAN.” Looking at your topology, if you have these routers in place without any tunneling mechanism (such as GRE, QinQ, or something else) then you cannot have HostA and HostB in the same VLAN. You may assign them with the same VLAN ID, but that doesn’t make them part of the same segment. Indeed, they are not in the same network segment because as you mention in your post, there are routing devices between them. In such a situation, Host A and Host B would have IP addresses in different subnets. In this case, ARP would not be used by Host A to determine the MAC address of Host B. ARP would be used by Host A to find the MAC address of the next hop, which would be Router A.

Now if you have tunneling mechanisms in place that allow VLAN 99 to span across the WAN, then Host A and Host B can actually be in the same network segment and have IP addresses within the same subnet. One of the most common methods of doing this is using QinQ, which allows you to span a VLAN across the WAN. This means that any broadcast sent from Host A would be tunneled and would reach Host B. And of course, this includes ARP requests.

I hope this has been helpful!

Laz

1 Like

Hello Laz,

Thank you again for the thorough response.

I’m still in the review phase of my CCNA preparations, and this topic isn’t an exam topic (so the materials don’t cover it), but I suspected that something like this had to work. Thank you for confirming it! :slight_smile: By the way, the reason why I was thinking that the VLANs should be in the same subnet in this case was that all materials say that it’s best practice to keep things straight and have the same IP subnet per VLAN. Although for a reason that doesn’t apply in the setup where the hosts are separated by routers.

If I remember correctly, this is the only situation where a misconfigured VLAN/subnet pair can cause issues (at least on a CCNA-level setup):

  1. All hosts are in the same VLAN (for example: VLAN 1).
  2. Host A’s subnet mask is misconfigured, and it thinks it’s in the same subnet as host B.
  3. Host A and host B aren’t separated by a router, only by one or more switch.

In this situation, host A thinks it can ARP for host B, and since (1) the destination address of host A’s frame is the all Fs MAC address, and (2) both hosts are in the same VLAN, and (3) there’s no router to stop/filter the broadcast frame, the switch(es) forward the frame out all the other ports, which means host A’s ARP reaches host B.

I wonder: would an L3 switch also stop the ARP frame by host A? Which of its functionalities would dictate its actions: forwarding the frame out all the other ports that belong to the same VLAN as the sender’s (its L2 logic), or filtering the frame because it’s a broadcast frame (its L3 logic)?

Thank you very much for your continued support! I hope I’m not asking too many questions. I just want to make sure that I’m as prepared as I can be when taking my exam, which I hope is going to be soon now (2-3 weeks maybe).

Attila

Hello Attila

It is indeed best practice to ensure that each VLAN you create corresponds to a different subnet/network segment, and you should make sure that all hosts within each VLAN/subnet/network segment have the correct subnet mask.

Now the rest of the scenario that you are describing is an interesting one. If both Host A and Host B are in the same VLAN, they should have the same subnet mask. However, if one subnet mask was misconfigured, then communication between those hosts would fail.

For example, let’s say Host A has an address of 10.10.10.10/24 and Host B has an address of 10.10.10.210/25. As far as Host A is concerned, Host B is in its own subnet, but as far as Host B is concerned, Host A is not in its own subnet. If Host A sends an ARP request for 10.10.10.210, it will essentially send a broadcast that will reach host B. Host B will respond with its MAC address with a unicast frame. Now because this communication is completely on Layer 2, IP addresses are not involved in getting the frame to the destination. So Host A will successfully learn Host B’s MAC address.

However, for all subsequent communication that uses IP addresses, Host B will always send traffic intended to Host A to the default gateway because it considers Host A outside of its own subnet.

An L3 switch will always contain an ARP request to within the VLAN from which it was sent. This is the nature of broadcast communication, and this is not limited only to ARP requests. Does that make sense?

I hope this has been helpful!

Laz

1 Like

Hello Laz,

Thank you.

“However, for all subsequent communication that uses IP addresses, Host B will always send traffic intended to Host A to the default gateway because it considers Host A outside of its own subnet.”

I’m not sure I understand why this would fail, but I have a theory.

Host B’s default gateway will know how to find Host A (or ARP for its MAC address), so Host B’s default gateway can send the frame to Host A. Host A will see that the frame is destined for it (Host A), because its (Host A’s) MAC address is in the destination field of the frame. Then, Host A sees that the frame’s source MAC address is not the one it (Host A) thinks Host B’s MAC address should be (because the frame’s source MAC address is that of Host B’s default gateway), so Host A updates its ARP cache. Host A’s updated ARP cache now matches Host B’s MAC address with the IP address of Host B’s default gateway.

Then I guess what happens next (and this is where things stop working, if I’m correct) is Host A, when it tries to contact Host B, is going to use the MAC address of Host B’s default gateway as the destination MAC address in the frame, and use Host B’s IP address in the packet’s destination IP address field. Then, Host B’s default gateway will see the mismatch between the destination MAC and IP addresses, and will drop the packet.

Is this why the communication fails?

Have a nice week.
Attila

Hello Attila

Hmm, not quite. Let me write it another way. Take a look at this diagram:
image

Note the subnet masks of each host and the router. Now, let’s go through the process of communication after the ARP request has been successfully received. So H2 wants to ping H1. It already has H2’s MAC address in its ARP table. Let’s see what happens:

H2 pings H1:

  • H2 prepares the packet with the destination IP address of 10.10.10.10
  • H2 sees that this IP address is outside of its subnet (the /25 subnet ranges from .129 to .255)
  • Therefore, H2 will send the packet to its configured default gateway.
  • It uses the ARP process to find the MAC address of the default gateway, populates the destination MAC and send it on its way.
  • When this reaches the switch, it will see the MAC address in the MAC address table and send it out of the port connected to the router.
  • The router will receive it, see that it is indeed its own MAC address, but it has an IP address that does not belong to it. If the router is configured correctly, it will route the packet out of the same interface, with the appropriate MAC address of H1.
  • It will go to the switch and be sent out of the interface that corresponds to the MAC address of H1 according to the MAC address table.
  • Finally the packet will reach H1.

But what happens in the opposite direction with the response to the ping?

  • H1 sees that H2 is in the same subnet (H1 tries to respond to the ping so it searches for the 10.10.10.210 address in its ARP table.
  • It looks it up but can’t find it, so it sends out an ARP request (broadcast)
  • When H2 receives this ARP request, it sees that the request comes from a device in another subnet that is not its own. So it drops the request.

The result is that H1 never gets to find out what the MAC address of H2 is. I’ve labbed this up using packet tracer, and you can see exactly this event in the following output:

image
So H1 gets a timeout and the ping response fails.

So traffic from H2 to H1 will reach its destination, while traffic from H1 to H2 will not.

Remember, this is a situation you should never have. Configuring different subnets is not best practice and will result in such unpredictable communication. Make sure your subnets are correctly configured.

I hope this has been helpful!

Laz

1 Like

PT.zip (49.6 KB)
Hi Laz,

Apologies for the long post.

Thank you very much for the detailed response.

One thing I don’t understand is that if H1 sees that a packet with the source IP of H2 arrives with the source MAC address of R1, why is it that H1 doesn’t map R1’s MAC address with H2’s IP address? For all H1 knows, what happened was it received a ping from a device that is in its own subnet, so H1 populates its ARP cache with this information.

Please allow me to introduce another related topic:

I’ve experimented with this scenario in Packet Tracer and found something interesting. Not sure if it’s a PT bug or something that works like this in real life (I have no access to real gear yet to experiment with). The interesting thing I found was if the ARP table of at least one host contains the MAC-to-IP mapping of the other host (it doesn’t matter which host this is), then the ping succeeds. It doesn’t matter which host thinks it’s in the same subnet as the other one, and who plays which role (sender or receiver).

Please note that I’ve changed the IP addresses from our earlier example, just for convenience (it was easier for me to change the subnet masks this way as I was experimenting).

Topology, default gateway, and host settings:

Both host’s ARP caches are empty. First ping attempt fails: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.

Second ping attempt succeeds: both hosts think they’re on the same subnet. The ARP caches of both hosts are now populated.

Third ping attempt succeeds: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.

Here are all possible scenarios. All pings succeed:

Sender thinks it’s in the same subnet as the receiver; sender’s ARP cache populated, receiver’s not:

Sender thinks it’s in the same subnet as the receiver; sender’s ARP table not populated, receiver’s is populated:

Sender thinks it’s in a different subnet; sender’s ARP cache not populated, receiver’s is populated:

Sender thinks it’s in a different subnet; sender’s ARP cache populated, receiver’s not

I’ve also played around with the tracert command.

To get the behavior where the traffic from PC1 goes through the router, you first

  1. start with an empty ARP cache,
  2. change the subnet mask of PC1 so that it’s in the /8 subnet (this will clear its arp cache),
  3. ping PC1 from PC0,
  4. change the subnet mask of PC1 so that it’s in the /24 subnet (other masks probably work as well),
  5. ping PC1 from PC0,
  6. do a tracert from PC0 to PC1,
  7. do a tracert from PC1 to PC0.

How the tracert command doesn’t work:

  1. start with an empty ARP cache,
  2. change PC1’s subnet to /8,
  3. issue a tracert from PC0 to PC1,
  4. change PC1’s subnet to /24,
  5. issue a tracert from PC1 to PC0.

Sometimes the above steps don’t work, but when I’ve restarted Packet Tracer, they did. So this all might be a PT bug.

I’ve uploaded the Packet Tracer lab for your convenience.

Can you please help me out what’s going on here?
Have a nice week.
Attila

Hello Attila

When H1 receives a packet with the source IP of H2 and the source MAC address of R1, it doesn’t map R1’s MAC address with H2’s IP address because it knows that the packet is coming from a different subnet. H1 expects the source MAC address to be the MAC address of the default gateway since the source IP address is in another subnet. That’s the definition of what routers do. So ARP will only populate its ARP table with MACs that correspond to IP addresses within their own subnet.

Now as for your scenario with Packet Tracer, thanks for being so thorough. From your experiments, it seems that the ping succeeds when at least one of the hosts has the correct MAC-to-IP mapping in its ARP cache. This behavior is not expected in real-life situations, and it’s likely a limitation or a bug in Packet Tracer.

In a real-life scenario, if a host has an incorrect subnet mask configured, it would not be able to communicate with hosts in other subnets as it would not send the packet to the default gateway (router) for forwarding. My hunch would be that this is indeed a limitation of Packet Tracer.

I hope this has been helpful!

Laz

Hello, everyone!

A quick question. If we have 3 hosts on the same segment - PC1, PC2 and PC3 and PC1 sends an ARP request to PC2, it will include its own sender information in the ARP packet (its MAC and its IP).

My question is, why won’t PC3 (who will receive this request as well, since it’s sent as broadcast) use it to create an ARP entry for PC1? I’ve tried this in a lab and was quite suprised that PC3 didn’t do so, despite having the sender’s MAC and IP right in the ARP packet.

Kind regards,
David

Hello David

The behavior is a matter of the particular host’s NIC operating mode: Normal or Promiscuous mode.

In normal mode, which is typically the default operating mode, a NIC only processes packets addressed to its own MAC address, as well as broadcast packets and multicast packets for which the NIC is specifically configured to listen. In this mode, when a NIC receives an ARP request that is broadcast, it will open it and take a look at the target IP address (the IP address for which the request wants to learn the corresponding MAC address). If that address is not its own, it will not process the request any further, and it will discard it. Even though the sender MAC and IP are available to it, it will not populate its ARP.

In promiscuous mode, the NIC processes all packets it sees on the network, regardless of the destination MAC address. It effectively “listens” to all the traffic in its network segment. If it receives an ARP request, it will look at the sender’s IP and MAC addresses and use that information to populate its ARP table.

Now what mode is the default, and what mode you are able to configure depends upon the host in question. On a Windows device, promiscuous mode is typically controlled by software applications that may require it. For example, Wireshark can be configured to use promiscuous mode to listen to and process packets arriving on a NIC.

I hope this has been helpful!

Laz