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 = [,,,,,
        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 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;
        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

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.


Attachment: signature.asc
Description: Digital signature

Reply via email to