[ixpmanager] IRRDB back-end not working

[Kyle Spencer]

Barry,

I think I better understand the issue now. Thanks.

I also think that your suggested solution is a good one: Essentially,
turn on IRRDB filtering in IXP Manager, and remove IRRDB filtering
elements from the BIRD config before pushing them to the daemon.

Regards,
Kyle Spencer

On Mon, Sep 18, 2017 at 10:14 PM, Barry O'Donovan
<barry.odonovan at inex.ie> wrote:
>
>
> 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
>
>
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> https://www.inex.ie/mailman/listinfo/ixpmanager



-- 
Cell/WhatsApp/Signal: +256790884905