[ixpmanager] IRRDB back-end not working

[Barry O'Donovan]

Kyle Spencer wrote:
> Surely it would be easy to just have the IRRDB system query and
> display the data in the Prefix Analyzer tool without actually enabling
> the filtering in BIRD unless that box is checked in the Customer
> interface?

The question is if we bung all this data into the database, what do you
think the tool will show you? The answer is: nothing useful.

The script [1] which populates that table on which the prefix analyser
works doesn't pay any heed to the IRRDB data in IXP Manager. Rather it
reads that data from the configuration file (see line 117 on the link in
[1]).

That's because the script dates from a time before we stored this data
in IXP Manager and before we used bgpq3.

So, unfortunately, no matter how quick or not a hack it is to do what
you want, it won't make a blind bit of difference to the analysis tool :-(

> There is extremely low IRRDB compliance in Africa based on my
> observations. It seems to me that, if this minor change could be done,
> it would greatly simplify the transition to IRRDB for African IXPs and
> their customers which, in turn, would improve the overall
> interconnection ecosystem's health across the region.

I'm all for this! More IRRDB filtering ftw. And, hopefully, onwards to
more secure methods in the future.

We also have plans for building a better tool for this which:

a) is not tightly coupled to Bird
b) is not tightly coupled to /our/ route server config style
c) is not limited to a single route server view on a single VLAN

Back to your issue: if you do it the way I suggest below (dedicated
route server with IRRDB filtering), you'll get a production route server
with IRRDB filtering enabled and a working route server prefix analysis
tool.

If you don't want to maintain two IXP Manager's during the transition,
there is another option.

1. stop the cron job which pulls and refreshes the route server config
2. turn on IRRDB on all members

You'll now have what you don't want: IRRDB filtering in the config files
everywhere. You can pipe this script through a filter (say using awk)
which removes the line with some regex and the line+1 for each of:

    if !(bgp_path.last ~ allas) then
           reject;

    if ! (net ~ allnet) then
            reject;

in each neighbour definition.

3. update cronjob script to filter / post process the config as above
4. you're back to status quo: one instance of IXP Manager and no
filtering in the config even though it's turned on in IXP Manager.

You can now set up a new route server without the awk script where you
actually filter prefixes and tie this into the analysis tool.

You then have the best of both worlds and only one IXP Manager instance.

 - Barry




[1]
https://github.com/inex/IXP-Manager/blob/master/tools/runtime/route-servers/compare-route-server-prefixes.pl

> 
> On Mon, Sep 18, 2017 at 5:08 PM, Barry O'Donovan <barry.odonovan at inex.ie> wrote:
>> Kyle Spencer wrote:
>>> If I enable IRRDB filtering, my IXP will implode due to the low level
>>> of compliance among my membership.
>>>
>>> However, I do want to work toward enabling it, and IXP Manager's
>>> Prefix Analyzer tool would be a very useful way for IXP members to
>>> check their compliance in advance.
>>>
>>> The IRRDB Prefix Analyzer interface suggests this is possible with the
>>> top-line message: "Warning! No ports have IRRDB filtering applied so,
>>> while this information is useful, it has no impact on your services."
>> I wouldn't pay too much heed to that message. The tool was not designed
>> for users who do not have IRRDB filtering enabled and everyone at INEX
>> does as a rule. We won't be developing that tool further as we think
>> this can be done better using large community tagging by the route
>> server on filtered routes.
>>
>> It can be a pain to migrate from no IRRDB filtering to using it but it
>> is highly highly recommended.
>>
>> If it we INEX, the way we'd probably do this is:
>>
>> a) parallel install of IXP Manager with database clone
>> b) migrate one route server (or create an additional one) that keys off
>> the second install
>> c) turn on IRRDB filtering on the second one
>>
>> There's overhead in that you need to keep the second in sync with the
>> first but you can script this quite easily (mysqldump ... | mysql;
>> followed by a single query to toggle the IRRDB flag).
>>
>> This is pretty much how we went about an peering LAN IP renumbering
>> recently.
>>
>>
>> LINX are in the middle of a similar exercise - see "IXP Route Server
>> Prefix Validation at LINX - Progress and challenges" at:
>>
>> https://indico.uknof.org.uk/event/40/timetable/#20170912
>>
>> There should be videos available shortly.
>>
>>
>>  - Barry
>>
>>
>> _______________________________________________
>> INEX IXP Manager mailing list
>> ixpmanager at inex.ie
>> https://www.inex.ie/mailman/listinfo/ixpmanager
> 
> 
> 

-- 

Kind regards,
Barry O'Donovan
INEX Operations

https://www.inex.ie/support/
+353 1 531 3339