Hi Viktor,
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
When all of these starts rolling-out, you would have a huge percentage of "not-found", that is why you would not want to deny those. There you can see the importance of generating your ROAs, although you are not particularly interested in filtering.
Regards and thanks Tim for the catch,
Roque
On Mon, Nov 15, 2010 at 11:27 AM, Viktor Steinmann stony@stony.com wrote:
Wouldn't that do it?
! route-map bar deny 10 match invalid !
Cheers, Viktor
On 15.11.2010 11:06, tim wrote:
Hi all,
About the talk "BGP Origin ASN Validation" from Roque Gagliano at SwiNOG #21 I talked afterwards with him with the following remark:
Roque showed a route-map like this one:
route-map foo seq 10 match invalid set local-preference 50 ! route-map foo seq 20 match incomplete set local-preference 100 ! route-map foo seq 30 match valid set local-preference 200 !
This will not fix the "youtube vs. Pakistan"-problem.
For example, youtube announces a /22, signed, gets local-pref 200. "Bad ISP" announces a /24 out of the /22, unsigned, gets local-pref 50, BUT gets into my routing table!
I think it whould by cool to have a system to prevent an *unsigned* prefix, which is more specific than a *signed* prefix, to be accepted.
Maybe this could be done in IOS Code, for example with the configuration option "do not allow an unsigned more specific prefix within a signed prefix".
This will allow us to configure the route-map as shown above and accept invalid/incomplete prefixes. But the accepted invalid/incomplete prefixes are not more specific than a signed prefix.
If someone does know more, please comment.
Cheers, Tim
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog