This counter increments every time a CFM frame was held back from flooding because the ingress or egress port involved was in an STP state other than forwarding, such as blocking, listening, or learning. Since CFM frames are Layer 2 multicast traffic subject to the same Spanning Tree rules as any other frame, this counter rises naturally whenever STP is actively pruning a redundant link, and a spike often coincides with a topology-change event elsewhere in the network. If this value jumps right after a link flap on a redundant uplink, that confirms STP correctly blocked that port rather than the CFM engine misbehaving.