So I’ve been reading a bit lately about Unicast Flooding and, in some blogs/forums, this issue surfaces as something which should be fixed! Here is the thing – not all scenarios require this fixing!
As you will see, unless you change some default parameters, Unicast Flooding will happen in your network at some stage! What you do need to figure it out is whether in your scenario you should fix it or not? And if you do have to fix it, how do you do it!?
Ok … so let’s see what unicast flooding is …
… but first, let me remind of how switching works:
- A switch populates its mac-address table with mac addresses registered on incoming frames. As a result, when the switch needs to forward a frame destined to that specific mac-address, it will know out of which port to send the frame.
- Flooding however occurs when the switch does not know of the destination mac-address – say the switch has not learnt that mac address yet; or maybe that specific entry expired so it got flushed away from the mac-address table. To ensure the frame reaches its intended destination, the switch will replicate that frame out of all ports, less the port where the frame was received – that’s flooding.
- By default, each mac-address table entry has a timeout timer of 5 minutes; this timer gets reset as relevant frames keep coming into the relevant port
When it comes to Layer3 forwarding, the ARP table will be used instead:
- A Layer3 device populates its ARP table by means of the ARP protocol. The process starts with an ARP-Request packet, followed by an ARP-Reply. The end result is the mapping between a destination IP address and destination MAC address.
- Should the mapping exist, obviously, an ARP-Request/ARP-Reply does not happen – unless that entry expires; the expiration timer is 4 hours by default and unlike the MAC-Address entry, it doesn’t get refreshed – once expired, a new ARP-Request is broadcasted out …
Before I proceed, I will use the topology below to illustrate what’s been discussed so far:
While on HOST2 we will now ping HOST1 …
… and take a look at the mac-address tables. We can see that SW-A learns the MAC address of HOST2, over the trunk interface between he two switches. Similarly, SW-B learns the MAC address of HOST1.
Here is an overview of what actually happens:
- ping 192.168.1.1 command is issued
- HOST2 sends an ARP request; it needs to know the MAC address of HOST1. If HOST1 was on another network, HOST2 would be ARP-ing for the default gateway MAC address instead
- In the meantime, HOST2 would get a ICMP request timeout (the “.”) – this is that first dot that you sometimes see when pinging an IP address
- At some stage the ARP resolution is successful so HOST2 knows which interface to use to send the packet out
- During the ARP process, since both switches participated by forwarding frames back and forth; the switches use information in those frames to populate their mac-address table – and this is how they learn the MAC addresses of each host
- SW-B looks at the Layer2 frame and sees that the destination MAC is somewhere out interface FA1/10 – so it will use this interface to forward the frame out.
- Similarly, once SW-A receives the frame, it looks at the Layer2 frame and sees that the destination MAC is somewhere out interface Fa1/1.
- HOST1 gets the frame, removes the Layer2 header and looks at the Layer3 information …
4 hours for an ARP entry vs. 5 minutes for MAC address entry – Rings a bell??
At some stage, the MAC entry will expire on either switches; so the switch will have no clue of where to send the frames! Remember that the switch has initially learnt the MAC address via the ARP process triggered by HOST2 – but there is no ARP process needed now since the ARP entry still exist; it’s the MAC-Adress-Table entry that disappeared!
So what is the switch going to do? It will replicate frames out of all ports … it will flood the broadcast domain!
Is this a big issue? Well … it’s not in this topology. Flooding will indeed occur …. once! Though the switches will update their mac tables accordingly once replies are sent back, as a result of the “initial” flooding.
This is really just to show how Unicast Flooding can happen in a simple, fairly standard topology. I also wanted to emphasise the fact this is not always a problem.
In Part II, I will show you one common topology where unicast flooding does become a problem.
Other Related Posts: