Hi All, As usually IXPs do, we also perform route filtering with prefix lists. In prefix lists we include only those prefixes which have corresponding "route" objects in RADB/RIPE. We don't accept by default longer prefixes, i.e. in prefix list we include, for example, 10.0.0.0/21 but not 10.0.0.0/21+. With the purposes of blackholing sometimes there is need to accept more-specific prefixes, mostly /32, from BGP peers. The easiest way is just to accept /32 in filter. But the main problem is that any peer can announce /32 route to any network, even to unreachable one. Thus there is need to additionally check /32 routes. For the first look, we may include longer prefixes to prefix list, and then check incoming /32 prefix against it. Result will look like: bird> show route protocol ITCONS 109.68.40.20/32 via 193.25.181.253 on vlan777 [ITCONS 2014-03-06 22:02:42 from 193.25.180.17] * (100) [AS25372i] 109.68.40.0/21 via 193.25.180.17 on vlan777 [ITCONS 2014-03-06 21:45:24] * (100) [AS25372i] i.e. filtering against [ 109.68.40.0/21+ ]. Now let's assume that 109.68.40.0/21 is reachable via other peer, and we got new route, and it is better due to as-path length, and new peer does not want to blackhole 109.68.40.20. Then "109.68.40.0/21 via 193.25.180.17" will become inactive, but "109.68.40.20/32 via 193.25.181.253 from 193.25.180.17" will stay best, and new peer will lose traffic to 109.68.40.20. Thus, it'd be reasonable to compare received /32 against routing table, and accept it only if there is active less-specific route from same peer. Personally I was not able to find solution for bird. Now I'm wondering how do other IXPs perform such filtering? Any ideas or thoughts are kindly appreciated! Thanks in advance! -- Alexander Shikov Technical Staff, Digital Telecom IX http://dtel-ix.net/