A 911 PSAP needs a special extranet peering where routes legitimately return with the PSAP’s own ASN in the path, which normal loop detection would drop. How should allowas-in be treated?
Select an answer to reveal the explanation.
Short Explanation
Allowas-in is cutting a hole in the ‘don’t accept your own ASN’ safety net. Sometimes an extranet design needs that hole—but you cut it only on that one peer, not on every ISP uplink, or you’ve invited routing loops to the party.
Full Explanation
BGP drops updates that already contain the local ASN to prevent loops. Allowas-in relaxes that check for scenarios such as certain extranets or hub-and-spoke overlays where the ASN reappears by design. A 911 PSAP needing special extranet peering where routes legitimately return with the PSAP’s own ASN should use allowas-in only on the controlled extranet peer that requires it, understanding it weakens AS-path loop detection. Scope it to the specific peer and depth required—not indiscriminately on public Internet edges.
Enabling allowas-in on every Internet-facing eBGP session as a default hardening step is dangerous and not hardening at all. Replacing allowas-in with Weight so AS-path loops are ignored AS-wide confuses local preference hacks with loop detection. Applying allowas-in solely on iBGP route reflectors to eliminate unique ASNs misunderstands where the feature applies.
Exam caveat: limit allowas-in occurrences and combine with careful filtering so only expected extranet prefixes are accepted. Operational check: enable allowas-in only on the extranet neighbor, confirm needed prefixes install, verify public ISP sessions still enforce normal AS-path loop checks, and document the exception for PSAP change control.