This post is a legacy post from my old weblog, it has been included as it seems to still have some hits. Old comments are included
Currently we are blocking bogon advertisements by using a prefix-list which we are updating manually. The problem with this approach is that whenever an address block is delegated by IANA to a RIR this list has to be updated manually. According to Team Cymru there is an easy fix for this problem and that's peering with there bogon route server.
In theory this looks like a nice solution to the problem, a centralized organ making sure the lists are up-to-date and spreaded to connected participants within a minute. However I was thinking about this today and there is a tiny glitch. And that is "what about more-specifics?". The bogon route server project makes sure you don't get another route matching the exact prefix, but a more-specific route will be accepted by your bgp process and nicely inserted in your routing table. So it looks like this approach only has very very little effect.
Some people use the argument that with the route set in your routing table packets destined for these locations will be blackholed, however in the DFZ you will never have these routes for starters so they already will be blackholed. And if they do appear they'll be routed to that destination, but that will also occur if we use the cymru bogon server (but only in the situation where this means more-specific routes).
The case that a more-specific bogon is announced is more common then that an entire /8 network is announced, so I think the bogon server is absolutely no solution for this problem, unless they are going to announce it in de-aggregates of say /27 it has some effect. To explain this a little more, let's take the following example:
CYMRU = remote router, OUR = our router.
CYMRU announces 18.104.22.168/8 tagged with their bogon community 65333:888
OUR sees the community and rewrites the nexthop to our blackhole IP.
OTHER announces 22.214.171.124/24
OUR sees the route, and enters it in the routing table with OUR's nexthop.
And voila bogons are happily traveling trough the network. Unless my understanding of the route-map is not 100%, this effectively shows that the CYMRU approach has no use whatsoever and static prefix-lists are the way to go.
We simply take these bogons BGP feeds and apply a routing mark to them… they do not get used in routing, just a simple list that we can now use to build other lists. We then take the bogon bgp feed and turn it into a firewall feed so that the packets are dropped at the firewall rather than done in the routing process. So – the bgp feed is not totally useless, you just have to think outside of the box.