What operators mean by “bogon”
A bogon (martian / unallocated source) is traffic whose source address is not routable on the public internet at that moment—IANA reserved space, unused allocations, or RFC6598 CGN ranges appearing where they should not. Seeing such sources on an internet-facing interface usually means spoofing, misconfiguration, or pathological routing—not legitimate endpoints.
Why filters exist
Ingress and egress filtering (BCP 38 / RFC 2827 spirit) prevents your network from accepting or emitting obviously forged sources. Team Cymru and RIR bogon feeds help automate updates as allocations change.
Enterprise context
Peering routers, DDoS scrubbers, and WAF/CDN edges often drop bogons before stateful inspection to save CPU. Logs should record drops at a sampled rate to avoid disk exhaustion during storms.
Representative ranges (operational view)
Examples commonly filtered as source addresses on internet-facing interfaces include 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 198.18.0.0/15 (benchmarking), 224.0.0.0/4, and 240.0.0.0/4—plus currently unallocated global space per IANA IPv4 assignments. Exact lists evolve; automate updates from Team Cymru or your RIR rather than hard-coding once.
BCP 38 / uRPF alignment
Ingress filtering (spirit of BCP 38 / RFC 2827) expects edge routers to accept only source prefixes that belong downstream. Strict or feasible uRPF on customer-facing interfaces reduces spoofed sources entering your AS. Combine with peering prefix limits so partners cannot leak bogons toward you.
False positives
Labs using documentation prefixes (TEST-NET) or overlapping RFC1918 in lab VRFs can trigger alerts in poorly scoped SIEM rules—tag lab traffic and exclude those VRFs.
Read CGNAT for why 100.64.0.0/10 may be valid on ISP WANs but not as a public source on your server farm.
Confirm what the internet sees as your source address when validating filters.