<div dir="ltr">How about using ROAs?<div><br></div><div><div>roa table roa_<span style="color:rgb(0,0,0);font-size:1em"> 64496</span> {</div><div> roa <span style="color:rgb(0,0,0);font-size:1em">192.0.2.0</span>/24 max 24 as 64497;<br>
</div><div>}</div></div><div><br></div><div>and then:</div><div><br></div><div><div>filter bgp_in</div><div>{</div><div> case roa_check(roa_112, net, bgp_path.first) {</div><div> ROA_INVALID: reject "Blocked - ROA_INVALID for ", net, " ASN ", bgp_path.first;</div>
<div> ROA_UNKNOWN: reject "Blocked - ROA_UNKNOWN for ", net, " ASN ", bgp_path.first;</div><div> ROA_VALID: accept;</div><div> else: reject "Blocked - ROA unknown reason";</div>
<div> }</div></div><div> ......</div><div>}</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 9:25 AM, Alexander Shikov <span dir="ltr"><<a href="mailto:a.shikov@dtel-ix.net" target="_blank">a.shikov@dtel-ix.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
As usually IXPs do, we also perform route filtering with prefix lists.<br>
In prefix lists we include only those prefixes which have corresponding<br>
"route" objects in RADB/RIPE. We don't accept by default longer prefixes,<br>
i.e. in prefix list we include, for example, <a href="http://10.0.0.0/21" target="_blank">10.0.0.0/21</a> but not<br>
<a href="http://10.0.0.0/21+" target="_blank">10.0.0.0/21+</a>.<br>
<br>
With the purposes of blackholing sometimes there is need to accept<br>
more-specific prefixes, mostly /32, from BGP peers. The easiest way<br>
is just to accept /32 in filter. But the main problem is that any<br>
peer can announce /32 route to any network, even to unreachable one.<br>
Thus there is need to additionally check /32 routes.<br>
<br>
For the first look, we may include longer prefixes to prefix list, and<br>
then check incoming /32 prefix against it. Result will look like:<br>
<br>
bird> show route protocol ITCONS<br>
<a href="http://109.68.40.20/32" target="_blank">109.68.40.20/32</a> via 193.25.181.253 on vlan777 [ITCONS 2014-03-06 22:02:42 from 193.25.180.17] * (100) [AS25372i]<br>
<a href="http://109.68.40.0/21" target="_blank">109.68.40.0/21</a> via 193.25.180.17 on vlan777 [ITCONS 2014-03-06 21:45:24] * (100) [AS25372i]<br>
<br>
i.e. filtering against [ <a href="http://109.68.40.0/21+" target="_blank">109.68.40.0/21+</a> ].<br>
<br>
Now let's assume that <a href="http://109.68.40.0/21" target="_blank">109.68.40.0/21</a> is reachable via other peer, and we got<br>
new route, and it is better due to as-path length, and new peer does not want to<br>
blackhole 109.68.40.20. Then "<a href="http://109.68.40.0/21" target="_blank">109.68.40.0/21</a> via 193.25.180.17" will become<br>
inactive, but "<a href="http://109.68.40.20/32" target="_blank">109.68.40.20/32</a> via 193.25.181.253 from 193.25.180.17" will<br>
stay best, and new peer will lose traffic to 109.68.40.20.<br>
<br>
Thus, it'd be reasonable to compare received /32 against routing table, and<br>
accept it only if there is active less-specific route from same peer.<br>
Personally I was not able to find solution for bird. Now I'm wondering<br>
how do other IXPs perform such filtering?<br>
<br>
Any ideas or thoughts are kindly appreciated! Thanks in advance!<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Alexander Shikov<br>
Technical Staff, Digital Telecom IX<br>
<a href="http://dtel-ix.net/" target="_blank">http://dtel-ix.net/</a><br>
</font></span></blockquote></div><br></div>