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.shikov@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/