Hello Mohammed
Ah yes, understood. Until now I was describing the situation after unicast flooding began, but there is a period in time, as you correctly state, where everything is working correctly…,.
As soon as all devices are turned on, the ARP tables and MAC address tables are empty. H1 sends a ping to H2, and this is what happens:
- The packet is received by SW1 and is routed to VLAN 20. At this point VLAN 20 knows the destination IP address, but not the destination MAC.
- ARP is used to learn of the destination MAC address, and this is flooded on VLAN 20. The ARP request is a broadcast, so it reaches all of VLAN 20 on both switches.
- H2 will respond with an ARP reply, and will send it to the VLAN 20 SVI on SW1. SW1 will update its ARP table.
- This ARP response has a the source MAC address of H2, so it will also be used to populate SW1’s MAC address table with H2’s MAC address. So now SW1 has both an ARP and a MAC address table entry.
- Another way in which H2’s MAC address is recorded on SW1’s MAC address table is when H2 performs an ARP request of its own for its default gateway. This too would reach SW1 and would populate the MAC address table.
This is how the correct MAC table and ARP table entries are obtained.
Now the ARP table caches its entries for four hours while the MAC address table for 5 minutes. If H2 remains idle for more than 5 minutes, SW1 will lose its MAC address table entry for H2. Any subsequent traffic that occurs will have an ARP table entry, but no MAC address table entry for H2 in SW1, and unicast flooding occurs. If H2 remains idle for more than four hours, then the ARP table is also purged, and correct ARP and MAC address table entries can once again be obtained.
I hope this has been helpful!
Laz