Unicast flooding walk through?
So I'm trying to get my mind around unicast flooding, as seen here http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml . Are there any good walk-throughs out there that break it down even simpler than that link? I've come up dry hitting my usual suspects for more info and I don't really have people to ask.
Posted Oct 21, 2012, 8:28 PM UTC
73
A switch receives a packet from host A intended for host B. The switch looks for the destination mac address in it's mac address table. It finds it doesn't know what port that particular mac address is connected to.
So it forwards the packet out every port except for the port that it received the packet on, (host A's port). Host B replies to the message with it's mac address in the source field. The switch looks at the packet and adds Host B's mac to it's mac address table. At this point, any packets with Host B's mac will be forwarded out that particular port.
I guess that can happen when the CAM table times out at the default 5 minutes but the IP/MAC still exist on the ARP table?
I was more referring to the following example though:
"Misconfiguration of networks may lead to unicast flooding as well. If there are two layer 2 paths from Host A to B and Host A uses path 1 to talk to Host B, but Host B uses path 2 to respond to Host A, then intermediate switches on path 1 will never learn the destination Mac address of Host B and intermediate switches on path 2 will never learn the destination MAC address of Host A.[3]" From: https://en.wikipedia.org/wiki/Unicast_flood
How does such a scenario come about? Would this be HSRP misconfigured on one end?
Sounds to me like STP isn't running or is not properly configured to block redundant links.
Edit: I actually read through the material in the links you posted and you're right about the ARP and CAM table timer difference causing the unicast flooding. HSRP is out of the scope of the Ccna so I can't say from a design stand point why it would be setup this way. It appears that you'd need to change the cam and arp timers to match so that this particular issue doesn't happen.