Improve performance & scalability whilst reducing Bogon related costs and resource drain
The Bogon Route Server Project provides bogon tracking and notification through a multihop eBGP peering session. This can make the automation of filters simple.
​
Bogon peering is available for traditional IPv4 bogons, IPv4 fullbogons 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 on occasion, most often because of a router configuration mistake. The Bogon Route Server Project can help you to avoid the propagation or the acceptance of these mistakes.
Caveats
-
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. KNOW YOUR NETWORK.
-
If you utilize RFC1918 space internally, you may wish to filter those announcements from the bogon route This can be accomplished with route maps or prefix lists. We cannot provide specific instructions for this; please consult your vendor’s documentation or other support resources for more detailed assistance.
-
​Bogon filtering should be undertaken only if the impacts are well-understood. These are not simple filters, and can have adverse impacts if improperly applied. In particular, please consult RFC6598 regarding 100.64.0.0/10. It’s important that you know your network, and that any planned filters are rigorously tested before adoption. These filters may be more applicable to some devices, such as gear that functions as a border router, than other devices.
Features
-
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.
-
We 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, as shown in 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.
Gory Details
The peering is conducted over a multihop eBGP peering session. The routers used for this peering serve no other purpose aside from the announcement of the bogon prefixes. We have bogon route servers online in the United States and Europe. We recommend that you peer with at least 2 separate route servers for redundancy and we configure 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 help in detecting and preventing route leakage.
-
We tag each route with a community to allow easy filtering. The bogon route servers use the community 65333:888, while the fullbogon route-servers use 65332:888.
-
Peering sessions are password protected.
-
The bogon and fullbogon route servers do not accept prefixes from their peers.
OpenBGP Users
Fix for OpenBGPD receiving dual stack over a single session: Both sides need to send MP IPv4 and MP IPv6. This is disabled by default. The receiving side needs to set “announce IPv4 unicast” and “announce IPv6 unicast”, even if they won’t actually send any of those routes.
Automatic Bogon Filtering
​So how does one use the community 65333:888 or 65332:888 prefixes to generate a bogon filter? There are several methods. 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.
Traditional Bogon Examples
​
​
​
​
​
Fullbogon Examples
Cisco IOS IPv4 and IPv6 (IPv4 transport)
​
Cisco IOS IPv4 and IPv6 (IPv6 transport)
​
​
​
​
​
​
Nokia SR OS IPv4 and IPv6 Classic CLI
​
Nokia SR OS IPv4 and IPv6 MD-CLI
​
​
​
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!
Obtaining a Peering Session
We typically provide two peering sessions per remote peer for redundancy. If you would like more or less than two sessions please note that in your request. We try to respond to new peering requests within one to two business days.
​
You must be able to accommodate up to 100 prefixes for traditional bogons, and up to 250,000 prefixes for fullbogons, and be capable of multihop peering with a private ASN. Please take care to configure your peering sessions properly. On occasion, we have received bogon packets routed to us! We will drop peering sessions if this happens to keep our services up and running.
​
System Requirements
The traditional bogons have been operating with a wide variety of BGP-speaking systems for a long time, and should work in most environments. IPv6 requires separate configuration and support is still inconsistent on many platforms. Please consult your documentation and vendor support resources if you encounter issues.
​
The fullbogons feeds are 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 250,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.
Please know we will always make our best efforts to provide an available and reliable service. Do keep in mind that this is a free service and there are no guarantees of uptime or response time.