On 19.03.2010 09:03 Wolfgang Hennerbichler wrote
On Mar 19, 2010, at 08:47 , Arnold Nipper wrote:
what I meant by checking the as-path was if the peer-as was in the as-path:
if ! (bgp_path ~ [= 1120 * =]) then reject;
ic ...
where pref_ASyyyy() simply matches against all prefixes found in RADB for AS yyyyy.
our members decided to not filter on RADB but RIPE and rather use the solution above instead of dropping prefixes.
afaik RIPE is a subset of what you get from RADB. I like RADB because of its features like being able to do whois -h whois.radb.net \!ias-telia,1 or whois -h whois.radb.net \!gas1299 for example. Piping to some sed and tr and you are done ;-)
Out of curiosity: How often do you rebuild your filters,
We did it only once the day, but current plans are to do it more often. Perhaps every 2h or so. Sebastian did not only work on Hoofprints but also spent some time on re-writing the filter generation software (incl. an aggregate6). Rebuilding the filters for ~370 AS-SETs now takes a little more than five minutes.
and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP. Documentation says: Changes in filters usually lead to restart of affected protocols. If soft option is used, changes in filters does not cause BIRD to restart affected protocols, therefore already accepted routes (according to old filters) would be still propagated, but new routes would be processed according to the new filters. However with _our_ current model, we only filter between customer table and master table, accepting everything from customer side. From what I've seen (more precise: meant to have seen) applying new filters does not trigger importing routes to the master table. Another question: what exactly is reloading a table doing. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333