Hello Laz.
Apart from this, this might have another use. Take a look at this topology
I’ve purposely connected the switches this way to demonstrate something. On SW20 (the switch directly connected to the root bridge), it takes it 20 seconds to respond if I cut the root bridge down.
SW20#
*Jul 1 10:32:37.877: STP: VLAN0001 rx BPDU: config protocol = ieee, pack
et from GigabitEthernet0/0 , linktype IEEE_SPANNING , enctype 2, encsize 17
The connection is then shutdown
*Jul 1 10:32:57.888: STP: VLAN0001 Gi0/0 tx BPDU: config protocol=ieee Data
Notice how it took it 20 seconds to react. This makes sense.
Now, let’s take a look at the switch all the way down (SW10). This switch is 10-hops away from the root bridge.
SW10#
*Jul 1 10:29:32.631: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from GigabitEthernet0/0 , linktype IEEE_SPANNING , enctype 2, encsize 17
The connection between SW10 and SW11 is then shutdown
*Jul 1 10:29:42.634: STP: VLAN0001 Gi0/0 tx BPDU: config protocol=ieee Data
It took it 10 seconds to react instead of 20.
I therefore don’t think that this timer is reset each time a BPDU is received. What actually happens is the Message Age of the BPDU is subtracted from the Max Age timer. Since the message age looks like this before it hits SW10
SW10 will therefore subtract 10 from the max age. It will therefore cause it to respond 10 seconds faster than it should. So the further away you are from the root, the faster the BPDU ages out.
So apart from preventing potential looping BPDUs, it also causes switches that are further away to age out this BPDU faster. I suppose that the reason for this is to account for the time it takes to propagate the BPDU all the way there and to not have the downstream switches delayed since it would be bad if the bottom of your topology had to wait 20 complete seconds although, for example, 5 seconds have already passed since this BPDU was created.
David