
Re: Switch address learning question
Quote:
If a recently reset switch that has 4 hosts, A-D, has information in its MAC table of all the hosts except for D, and host A sends a frame to host D, would the switch be smart enough to know that by process of elimination, it does not need to flood the network segment with a broadcast of that frame to get the destination MAC address?
I'll start this explanation with a minor clarification. If a switch hasn't learned the MAC address that's in the destination address of a packet, it will retransmit (not broadcast) the frame to every port. This repeating of data is fundamentally different than a MAC layer broadcast, which is a packet that is retransmitted to all ports on a switch regardless of the switch's learned MAC address table.
In your scenario above, the problem is that the switch doesn't know the MAC address of whatever is plugged into that last port. The switch can't assume anything. What if host A is actually sending a frame to the MAC address of host E, which isn't even on the network? If the switch incorrectly identifies the MAC addresses associated with a port, the entire switching process will be broken.
You also can't assume that one port=one device. It's very common to connect (or "uplink") switches together, which means that a single port on a core switch might service hundreds of MAC addresses! Eventually the switch learns about all of them, but it might take some time before that happens. The retransmission of the frame across every port helps during this learning process.
We have this weird tendency in our industry to name normal-everyday-and-completely-necessary functions after some type of disaster (i.e., collision, flood). The transmissions of unknown MAC address destinations to every port is a normal part of the switching process and it shouldn't be considered a "bad thing."
As an aside, you usually don't see the scenario you described because the source device has already sent an ARP for the destination device as a MAC layer broadcast. If the destination device for the ARP is on the IP subnet, it will have already sent a reply with it's MAC address. Once the destination device responds to the ARP, the switch sees the conversation and adds the source MAC address of the ARP response to its lookup table. The ARP discovery conversation goes something like this:
----
Device A: I need to send some information to device D. I have his IP address, but not his MAC address. I wonder what his MAC address is? I'll send an ARP to find out. Hello everyone, is device D out there? Here's his IP address. If you are device D, please respond back with your MAC address.
Device D: Hi Device A, nice to hear from you, here's my MAC address if you want to talk directly to me. Since I'm sending this frame directly back to you, our layer 2 switch will now see my traffic and add my MAC address to its lookup table.
Device A: Thanks for the reply, Device D. I've also added you to my local ARP table and now I can talk to you directly through your MAC address.
----
This is a process that happens constantly on every network around the world. You can't talk to other devices on your local network unless you know their MAC address, so the ARP process is a fundamental part of networking.
Want to see what MAC addresses your system knows? Pop out to a command prompt and run "arp -a" on Windows or just "arp" in Linux.