A city traffic-operations center must stop the same 911 subnet from feeding back between OSPF and EIGRP. When is a prefix-list deny a better primary control than tag-based policy alone?

Tag-based policy is powerful when many redistributed routes should share a sticky label. A prefix-list deny is a better primary control when the traffic-operations center already knows the exact 911 subnet or subnets that must never feed back between OSPF and EIGRP—regardless of whether tags were set, stripped, or mis-assigned. Denying those known prefixes on redistribution provides a deterministic “never this network” gate that does not depend on tag-state consistency across borders.

The choice saying every redistributed route must keep circulating for troubleshooting is opposite of the goal: circulating every redistributed route prolongs loops. The choice saying administrative distance must be set to 255 on both protocols first would prevent installation entirely and is not a targeted 911 feedback control. The choice saying only BGP communities can identify IGP 911 subnets is false: BGP communities are not required to identify IGP 911 subnets, and IGP prefix-lists match those prefixes directly.

Exam caveat: prefix-list denies do not help if the looping prefixes are unexpected summaries or constantly changing; tags handle that class better. For fixed PSAP/911 blocks, prefix-list deny on both redistribution directions is clear and auditable. Combining an exact deny for the 911 subnet with tagging for broader municipal prefixes is a robust pattern. Mind ge/le so you deny the precise 911 length without over-blocking unrelated civic space.

Operational check: show ip prefix-list | include 911 (or the specific block) and verify deny sequences hit on redistribute evaluation. Confirm show ip route <911-prefix> has a single stable source protocol after the deny is applied. Attempt a controlled redistribution without the deny in lab to prove the prefix would otherwise feedback, then reapply the deny for production.