Bogons via BGP
Be sure to check out the main Bogon Reference for more information on the project and terminology used, and why it is important to keep your bogon filters up-to-date.
The Bogon Route Server Project provides bogon tracking and notification through a multihop eBGP peering session. This can make the automation of filters quite simple for even the largest networks.
Bogon peering is available for traditional IPv4 bogons, as well as both IPv4 and IPv6 fullbogons. The traditional bogons are martians plus prefixes that have not been allocated by IANA to an RIR; fullbogons also include prefixes that have been allocated to an RIR, but have not been assigned by that RIR to an ISP or other end-user organization.
Bogons do leak into the global table occasionally. This is generally a mistake on a router. The bogon route-server can help you to avoid the propogation of such mistakes or the acceptance of such prefixes.
Other methods of bogon tracking and filtering can be found on the Bogon Reference Page.
N.B.: Please remember that this is a free service. It comes with no warranties or guarantees. You own your own network, and are responsible for the (mis)use of this data. We do hope it is useful to you and your network. KNOW YOUR NETWORK.
Please note that if you utilize RFC1918 space internally, you may wish to filter those announcements from the bogon route-servers. This can be accomplished easily with route-maps or prefix-lists. Unfortunately, due to the broad variety of devices and configurations in use, we cannot provide specific instructions for this; please consult your vendor's documentation or other support resources for more detailed assistance.
Bogon and fullbogon peering use different ASNs on the Team Cymru side, and can both exist on the same router (as a transition mechanism, or to allow for different policies depending on the type of bogon received).
We can advertise all fullbogons (IPv4 and IPv6) over a single BGP peering session, with transport over either IPv4 or IPv6. Traditional bogons remain available over IPv4 transport only at this time. We'll provide assistance in setting up the peering sessions. The recommended configuration is for all bogons and/or fullbogons to be null routed on the peer side, and this is described in the examples below.
The traditional bogon list is manually updated as IANA allocates new blocks to RIRs, standards change, etc. The fullbogons list is automatically generated several times per day.
The peering is conducted over a multihop eBGP peering session. The routers used for this peering are a collection of one-armed routers of various shapes and sizes; these serve no other purpose aside from the announcement of the bogon prefixes. There are currently bogon route-servers online in the United States and Europe. We strongly recommend that you peer with at least 2 separate route-servers for redundancy, and will set up sessions this way by default.
The bogon prefixes are announced unaggregated, while fullbogon prefixes are announced aggregated. The ASN used by the bogon route-servers is 65333, and the fullbogon route-servers use 65332. Private ASNs are used to ensure that leakage is easily detected and prevented. Each prefix is tagged with a community to more readily enable filtering. The bogon route-servers use the community 65333:888, while the fullbogon route-servers use 65332:888. Peering sessions include the use of a password. The bogon and fullbogon route-servers accept no prefixes from their peers.
So how does one use the community 65333:888 or 65332:888 prefixes to generate a bogon filter? There are myriad methods, of course. One possible method is to use a route-map and a route with a next-hop of the null0 (Cisco) interface. We have collected examples below from our own experience and from several helpful contributors, which you may view by following the links below.
If none of these methods will work for you then please contact us for assistance. We are also eager to hear your suggestions on other filtering methods!
We will typically provide multiple peering sessions (at least 2) per remote peer for redundancy. If you would like more or less than 2 sessions please note that in your request. We try to respond to new peering requests within one to two business days, but, again, can provide no guarantees for this free service.
Remember that you must be able to accommodate up to 100 prefixes for traditional bogons, and up to 50,000 prefixes for fullbogons, and be capable of multihop peering with a private ASN. If you improperly configure your peering and route all packets destined for bogon addresses to the bogon route-servers, your peering session will be dropped.
The traditional bogons have been operating with a wide variety of BGP-speaking systems for a long time, and should work consistenly in any number of environments. IPv6 changes the ballgame somewhat; despite its nominal age, support is still inconsistent on many platforms, so please consult your documentation and vendor support resources if you encounter oddities. The fullbogons feeds are also MUCH larger than the traditional bogons due to allocation fragmentation; if you're receiving both sets of fullbogon prefixes we would recommend that your peer be able to handle at least 85,000 or more prefixes and be able to support IPv6 routing. Both of the lists might grow significantly as the bogon ranges change and get subnetted down in prefix size.
You can view the current lists in the HTTP section.
This is a free service there are no guarantees of uptime or response time - we'll make our best efforts, of course, but no promises of anything!