BGP & Routing

Bogon IP Checker

Check whether an IP address or CIDR prefix is a bogon — private, reserved, documentation, loopback, or multicast address that should not appear in public routing.

Check IP or Prefix

About Bogon IP Addresses

Bogon prefixes are IP address ranges that have not been allocated for public internet use. The term "bogon" comes from "bogus" and refers to address space that should never appear in public BGP routing tables or as source/destination addresses in public traffic.

Common Bogon Categories

Private ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — used in internal networks
Loopback (RFC 5735): 127.0.0.0/8 — localhost addresses, never leave the host
Link-local (RFC 3927): 169.254.0.0/16 — auto-configuration, single segment only
Documentation (RFC 5737): 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — for examples and documentation
Multicast (RFC 5771): 224.0.0.0/4 — group communication, not unicast routable
Reserved: 240.0.0.0/4 and other IANA-reserved ranges not yet allocated

Why Filter Bogons?

ISPs and network operators implement bogon filtering as part of BCP38 (Network Ingress Filtering, RFC 2827) to prevent IP spoofing. Traffic claiming to originate from bogon addresses is definitively spoofed since those addresses are not routable on the public internet. MANRS (Mutually Agreed Norms for Routing Security) recommends bogon filtering as a core practice.

Expert guide · Bogon Prefix Checker

What it does

The Bogon IP Checker compares an IPv4 address, or the network address of a prefix you paste, against a built-in table of fifteen special-purpose ranges that must never appear as sources or routes on the public Internet: RFC 1918 private space, RFC 6598 shared CGNAT space, loopback, link-local, the three RFC 5737 documentation networks, benchmarking space, multicast, the former Class E block and limited broadcast. It reports whether the address is a bogon, the category, the exact range it fell into, and shows the full reference table.

Why it matters

Spoofed DDoS traffic: Packets arriving from the Internet with a source in 10.0.0.0/8 or 198.18.0.0/15 cannot be legitimate, so dropping them at the edge removes a slice of reflection and flood traffic for free.
Route filter hygiene: An eBGP session that accepts 192.168.0.0/16 or 100.64.0.0/10 from a peer means your prefix filters are missing or broken, and the same gap will let real leaks through.
Log triage: An attacker IP in a SIEM alert that turns out to be 100.64.x.x is your provider's CGNAT, not a remote host, which changes who you need to call.
Documentation safety: Using 192.0.2.0/24, 198.51.100.0/24 or 203.0.113.0/24 in runbooks and examples guarantees that copied configs never point at someone's real server.
Address planning: Picking an internal range that collides with CGNAT space or benchmarking space creates routing ambiguities that surface only when a VPN or carrier link is added.

How to read the results

Is bogon: Yes when the address falls inside one of the fifteen special-purpose ranges; No means it is outside them, not that it is allocated or routed.
Type: private, reserved, loopback, link-local, documentation, multicast or broadcast for a match, or clean when nothing matched.
Matched range and description: The exact CIDR block and the RFC behind it, for example 100.64.0.0/10 Shared address space (RFC 6598).
Prefix input: Only the network address before the slash is evaluated, so 10.0.0.0/7 is reported as private even though half of it is public space; check prefix boundaries yourself.
IPv6 input: The tool returns a notice that IPv6 bogon checking is not implemented; use the IPv6 ranges listed in the background section instead.
Reference table: The complete list the checker uses, handy for building router prefix-lists or firewall object groups.

Technical background

Operators use bogon for any address that should never be seen on the public Internet, and the term covers two different lists. Martians are fixed by standards: the IANA special-purpose registries defined in RFC 6890 collect them. They include 0.0.0.0/8 (this network), 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 from RFC 1918, 100.64.0.0/10 shared address space from RFC 6598, 127.0.0.0/8 loopback, 169.254.0.0/16 link-local from RFC 3927, 192.0.0.0/24 for IETF protocol assignments, the documentation blocks 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 from RFC 5737, 198.18.0.0/15 for benchmarking from RFC 2544, 224.0.0.0/4 multicast, 240.0.0.0/4 reserved and 255.255.255.255. This tool checks exactly that martian set for IPv4.

The second list, often called fullbogons, adds space that is valid in principle but has not been allocated by IANA or an RIR to anyone. That list changes every week as registries hand out and recover blocks, so it must be consumed from a maintained feed delivered over BGP, as text files or through route-server sessions; Team Cymru publishes the best-known one. Since IANA's free IPv4 pool ran out in 2011, IPv4 fullbogons are mostly RIR-held space not yet assigned, while in IPv6 most of the address space is still unallocated. This checker does not include fullbogons, so a clean result for an unallocated address is expected.

Stale filters cause their own outages. When IANA gave 1.0.0.0/8 to APNIC in 2010, networks with hand-written bogon lists kept dropping it, and years later operators of 1.1.1.1 still found equipment treating that address as internal. The rule is simple: hard-code martians, which never change, and automate fullbogons or skip them entirely.

Filtering happens in two places. On BGP sessions, RFC 7454 recommends rejecting martian prefixes and anything longer than /24 in IPv4 or /48 in IPv6 from peers and transit. On the data plane, BCP 38 (RFC 2827) and BCP 84 (RFC 3704) ask networks to drop packets whose source address could not legitimately come from that interface; unicast reverse path forwarding automates this. Shared space deserves care: 100.64.0.0/10 legitimately shows up inside a provider network that runs CGNAT, and in traceroutes from its customers, which is common across Latin American broadband and mobile operators, but it must never leave the provider's edge.

For IPv6, the key ranges are ::/128 and ::1/128, 2001:db8::/32 for documentation (RFC 3849), fc00::/7 unique local addresses (RFC 4193), fe80::/10 link-local and ff00::/8 multicast. Many operators filter IPv6 by allowing only 2000::/3 global unicast and rejecting everything else.

Common errors and how to fix them

Problem A static bogon prefix-list written years ago still blocks blocks that RIRs have since allocated.: Fix Keep only the RFC 6890 martians in static lists. If you want fullbogon filtering, consume it from a feed that updates automatically, and audit any list that contains entries like 1.0.0.0/8 or 100.0.0.0/8.
Problem Filtering 100.64.0.0/10 on internal interfaces of a network that runs CGNAT.: Fix Allow shared space inside the provider domain, between CPEs and the CGNAT, and filter it only on external eBGP sessions and on the Internet-facing edge.
Problem Choosing 198.18.0.0/15 or 100.64.0.0/10 for an enterprise LAN because RFC 1918 space was already crowded.: Fix These ranges have specific purposes and collide with lab gear and carrier networks. Renumber into unused RFC 1918 space, or move internal services to IPv6 with unique local or global addresses.
Problem No source address validation on customer-facing ports, letting customers send spoofed packets.: Fix Enable strict uRPF on single-homed customer interfaces (ip verify unicast source reachable-via rx on Cisco, rpf-check on Junos) and loose mode or ACLs where traffic is asymmetric.
Problem Accepting /25 or longer IPv4 routes and private ranges from a transit provider.: Fix Apply an inbound policy on every eBGP session that rejects martians and IPv4 prefixes longer than /24 (IPv6 longer than /48), and reject private or reserved ASNs in AS_PATH.

Do it from the command line

macOS

# Is an address globally routable? (False for bogons)
python3 -c "import ipaddress; print(ipaddress.ip_address('100.64.1.1').is_global)"
# Download the maintained fullbogons list for IPv4
curl -s https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt | head -20

Windows

# Same check with the Python launcher
py -c "import ipaddress; print(ipaddress.ip_network('198.18.0.0/15').is_private)"
# Fetch the fullbogons list in PowerShell
(Invoke-WebRequest https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt).Content -split "`n" | Select-Object -First 20

Linux

# Which route would the kernel use for a bogon? (should not be your default gateway)
ip -4 route get 198.18.0.1
# Drop inbound packets with RFC 1918 sources on the WAN interface
sudo iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
# IPv6 fullbogons list
curl -s https://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt | wc -l

Frequently asked questions

What is a bogon IP address?

A bogon is an address that should never appear on the public Internet, either because it is reserved for a special purpose, like private networks, loopback or documentation, or because no registry has allocated it yet. Packets from bogon sources are usually spoofed or misconfigured, and BGP routes for bogon prefixes indicate a leak or a filtering failure, so networks drop both at their borders.

Is 100.64.0.0/10 a private IP range?

Not exactly. RFC 6598 defines it as shared address space for carrier-grade NAT, the link between a subscriber's router and the provider's NAT. It behaves like private space in that it is not routed on the Internet, but it is reserved for service providers. Enterprises should not use it internally, because it will collide with any carrier that uses it on the access network.

What is the difference between bogons and fullbogons?

Bogons, or martians, are the fixed special-purpose ranges defined by standards, such as RFC 1918 and RFC 5737 blocks. Fullbogons add every block that IANA or the RIRs have not allocated yet. The first list rarely changes and can be hard-coded; the second changes weekly and must be updated automatically, otherwise you will eventually block newly allocated legitimate networks.

Why do I see 10.x or 100.64.x addresses in my traceroute?

Many providers number their internal router links with private or shared space to save public IPv4. Those hops reply to traceroute with their internal addresses, so you see them in the path even though the destination is public. It is normal and harmless; what should never happen is receiving packets or BGP routes from the Internet that carry these addresses as source or prefix.

Can I use 192.0.2.0/24 in my lab network?

It is reserved for documentation, so it works technically in an isolated lab, but it is a poor choice: some devices and filters treat it as bogon and drop it, and examples using it might be confused with real configuration. For labs, use RFC 1918 space, or 198.18.0.0/15 specifically when you are benchmarking network equipment as RFC 2544 intends.