On May 22, Arnold Nipper <arn...@nipper.de> wrote: > Imho there are zillions of ways to do a configuration. Maybe that's why > Ondrej is asking for an example of input and output.
I choose the multiple RIB+pipe approach, so something like this is generated for each peer. Then there are the common functions invalid_prefix() (for filtering bogons), bgp_in() ("bgp enforce-first-as"-like check) and bgp_out() (for filtering community-controlled selective announcements). The output format is defined by a template, so if anybody likes a different configuration approach (why?) it can be modified to taste. function bgp_seeweb_in(int peeras) prefix set seeweb_in; { seeweb_in = [ 14.128.0.0/24, 14.191.0.0/22, 14.255.0.0/16, 31.0.0.0/16, 31.1.0.0/21, ... ]; if !(bgp_in(peeras)) then return false; if !(net ~ seeweb_in) then return false; return true; } table T_SEEWEB; protocol pipe P_SEEWEB { table master; mode transparent; peer table T_SEEWEB; /* routes from the global table to seeweb */ export where bgp_out(12637) = true; /* routes from seeweb to the global table */ import where bgp_seeweb_in(12637) = true; } protocol bgp SEEWEB { description "Seeweb"; neighbor 92.60.70.5 as 12637; local as 64725; table T_SEEWEB; rs client; interpret communities no; route limit 1000; # hold time 24; # keepalive time 7; connect retry time 3600; passive; import all; export all; } The input is a series of entries (formally a list of associative arrays) like this one: - as: 12637 description: Seeweb import: AS12637:AS-CUSTOMERS ip: 92.60.70.5 YAML is a serialization format supported by many languages, so the neighbors database can be trivially generated from e.g. a web-driven SQL database. I am interested in implementing new features in rpsltool, so please everybody let me know if you would like to do something which is currently not supported. -- ciao, Marco
signature.asc
Description: Digital signature