On Fri, Mar 07, 2014 at 10:43:28AM +1300, Andy Linton wrote: > How about using ROAs? > > roa table roa_ 64496 { > roa 192.0.2.0/24 max 24 as 64497; > } > > and then: > > filter bgp_in > { > case roa_check(roa_112, net, bgp_path.first) { > ROA_INVALID: reject "Blocked - ROA_INVALID for ", net, " ASN ", > bgp_path.first; > ROA_UNKNOWN: reject "Blocked - ROA_UNKNOWN for ", net, " ASN ", > bgp_path.first; > ROA_VALID: accept; > else: reject "Blocked - ROA unknown reason"; > } > ...... > } It will have the same effect like comparison against prefix list. 192.0.2.0/24 received from some peers may be valid from all of them But /32 from 192.0.2.0/24 may be received from peer without 192.0.2.0/24 as best path.
> > On Fri, Mar 7, 2014 at 9:25 AM, Alexander Shikov <a.shi...@dtel-ix.net>wrote: > > > 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/ > > -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/