Evidence, not intention
A transparent bridge has no configuration to tell it where anything is. It has one source of truth: frames arriving. IEEE 802.1D §7.8 hands the Learning Process the source MAC address and creates an entry only if four conditions hold at once: the receiving port is in a state that allows learning, the source address "denotes a specific end station, i.e., is not a group address", no conflicting static entry exists, and the table has room. 802.1Q 8.7 says the same in its own words — an Individual Address, not a Group Address — and splits the rest between 8.6.1 and 8.8.3. The destination address is never given to that process at all — it is used only as a lookup key.
The reason is not stylistic. The source address is evidence: the frame physically arrived through that port, so whatever sent it is reachable that way. The destination address is an intention, and says nothing about where the addressee is. Learning from it would install an entry pointing back at the sender's own port — precisely the wrong one — and create a black hole. The standard makes that structurally impossible rather than merely discouraged.
The corollary is visible on the sheet: a broadcast is never learned from as a destination, yet the switch learns plenty from the source of that same broadcast. An ARP request teaches the switch where the asker is, and nothing at all about who is being asked for.
Four outcomes, no special cases
Everything a bridge does with a frame falls out of two rules. First, 802.1D 7.7.1, "Enforcing topology restriction": a port is a candidate for transmission only if the ingress port was forwarding, the egress port is forwarding, the egress port is not the ingress port, and the frame fits the egress link's MTU (this lab does not model that last one). Second, egress filtering: with an entry for the destination, every candidate that is not the entry's port filters the frame.
From those two come flood (no entry, or a group address), forward (an entry pointing at another port), filter (an entry pointing back at the port the frame came in through, so nothing takes it) and discard (a reserved destination, or a port that is not forwarding). There is no clause anywhere that says "if source and destination share a port, discard". That behaviour is emergent, and presenting it as a rule would be a lie.
Ageing, moving, and running out of room
Entries are not permanent. The recommended default ageing time is 300 seconds — 802.1D table 7-4 and 802.1Q 8.7.3 with table 8-9, range 10 to 1 000 000, and IEEE 802.1's own YANG module publishes the same. Recommended, not required, and no vendor offers the whole range: Aruba AOS-CX allows 60 to 3600, Extreme 15 upwards. Cisco Catalyst, Juniper, Extreme and Aruba do ship 300; the Nexus 5600/6000 ships 1800. Static information is exempt: "It shall not be automatically removed by any ageing mechanism" (802.1D 7.9). And a topology change does not shorten the timer on modern gear — RSTP flushes what was learned on the affected ports, which is why a table that goes blank for no obvious reason is usually a topology change rather than a fault. (The 1998 STP did shorten it; that is the mechanism the old documentation describes.)
An address lives on exactly one port at a time. When the switch sees it arrive through another, it erases the old row and writes the new one — and if frames keep arriving through both, it keeps rewriting and packets are lost on every swap. That is MAC flapping, and the classic cause is a loop: with no spanning tree the flooded frame comes back through a different port with its source address intact, so the switch concludes the host moved. A rule that is correct in a tree becomes destructive without one. But not every flap is a loop: a Wi-Fi client roaming between two access points that bridge locally produces the same movement, with no damage — with a controller in the middle the address lives behind the controller's port and never moves.
The table is finite — the Catalyst 9300 datasheet says 32 000 entries — 64 000 on its higher-scale models —, and a Catalyst 9500 High Performance reaches 82 000 only on the Distribution SDM template, 32 000 on the one it ships with — and when it fills, new addresses are not learned and traffic to them is flooded. The switch has not entered some "hub mode": there is no such mode. What happens is that every lookup fails, and a failed lookup already has defined behaviour. That is the whole of the CAM overflow attack, and the whole reason port security exists: the table is a shared, exhaustible resource, and without a per-port quota one port can consume all of it. It is also reversible, because ageing empties the table on its own. Be careful with the conclusion, though: Cisco calls asymmetric routing one of the two most common causes of flooding, and table overflow "possible but rare" — so overflow is the last hypothesis to reach for, not the first.
