When a RSTP bridge detects a topology change:
?It starts the TC While timer with a value equal to twice the hello time for all its non-edge designated ports and its root port if necessary.
?It flushes the MAC addresses associated with all these ports. Excepting the port that received the TCN
My question: why would the switch keep in CAM the very addresses learned through the port that received a TCN ? Obviously on that branch of the STP tree something happened and I would rather keep the addresses learned through the other ports
In an L2 network, there is always a unique path between two devices. That's in fact the definition of a tree, and STP just block some ports to reduce the network to a tree, that provides at least the same connectivity as the physical network. When this tree is recomputed, typically as a result of a link coming up or down, the path between two devices may change. From the point of view of a bridge, a host that used to be reach over one particular port is not reachable through another port. Practically, it means that a mac address that was learnt on a port might need to "move" to another port. That's for the general introduction;-)
Now, RSTP is particular in the way that it only generates a topology change as a result of a port going up, adding connectivity. The idea is that, if a link is going down, the tree is split and you have two solutions:
- there is no redundancy, in which case there is no need to flush any mac address because the host that are in the now remote part of the network will not be reachable any more, regardless of the cam entries associated to them.
- there is redundancy, in which case RSTP will unblock a port, i.e. put a port to forwarding, i.e. generate a topology change.
Another difference between RSTP and STP is that the topology change indication (TC) is now originated from the port that is coming up.
So, when you received a TC on a port X, this port is on the (unique) path to a port Y that has just come up. It means that we are adding connectivity on this port: more mac addresses are now reachable through X. Those mac addresses could have been learnt on some other ports on the same bridge and could lead to black holing -> you need to flush those mac addresses on the *other* port. You don't need to flush the addresses on the port that has received the topology change, because none of them are leading to the wrong direction. A mac address on this port X could only be in the wrong direction if a host that was learnt on X was now reachable through a port Z on the switch. If this was the case, port Z would receive a topology change;-) So in fact, mac addresses on port X are the only one that can be preserved when you received a topology change on X (well, edge port are not flushed either).
That was a longer explanation than I thought would be necessary when I started typing;-) I hope it makes sense, let me know.