A police records bureau hardens its civic Internet edge. Which inbound eBGP practice best matches filtering bogon and unallocated space?
Select an answer to reveal the explanation.
Short Explanation
Bogon filtering is the nightclub bouncer at the civic edge: private, reserved, and unallocated prefixes don’t get a stamp. Don’t take a full table on faith—check the guest list on the way in.
Full Explanation
Inbound eBGP filtering should drop martians, bogons, and unallocated space that must never appear as valid Internet routes toward the civic network. A police records bureau hardening its Internet edge should apply inbound prefix filters—and preferably RPKI- or IRR-informed policy—that reject bogon, martian, and unallocated ranges. Combining prefix lists with provenance checks strengthens defense beyond crude AS-path length heuristics and reduces exposure to spoofed or garbage prefixes in the civic RIB.
Accepting a full table with no prefix filters so default routing can cover orphans increases exposure rather than hardening the edge. Relying solely on AS-path length checks because bogons always arrive with path length greater than 50 is false and incomplete as bogon policy. Disabling BGP scanning so invalid next hops never appear does not implement bogon or martian filtering.
Exam caveat: keep bogon and martian lists updated as allocations change, and pair filtering with max-prefix limits and RPKI invalid drop where the NOC is operationally ready. Operational check: apply inbound filters on ISP sessions, test that known bogon space is rejected, confirm legitimate customer and ISP prefixes still install, and monitor filter hit counters during incident windows.