[ixpmanager] some questions re: IXP 5

[Barry O'Donovan]

Hi Athanasios,

Athanasios Douitsis wrote on 30/10/2019 14:32:>>>> 
- We have setup the latest BirdsEye in our route servers and have
>>>>     successfully integrated with a test 5.2 installation. The looking
>>>>     glass in our 5.2 installation detects prefixes that are being
>>>>     filtered, by examining their BGP large community. All good as far as
>>>>     we can tell. However, when we look at the "filtered prefixes" tab in
>>>>     any member's page, we see no filtered prefixes. Can we inquire as to
>>>>     which exactly is the interdependency between what is seen in the
>>>>     looking glass and what is seen in the per-member "filtered prefixes"
>>>>     tab? How do we get to see (if possible) the filtered prefixes in the
>>>>     tab?
>>>
>>> Have a look at the documentation here:
>>>
>>> https://docs.ixpmanager.org/features/route-servers/#displaying-filtered-prefixes
>>>
>>>
>>> and this issue:
>>>
>>> https://github.com/inex/IXP-Manager/issues/575
>>>
>>> and let us know if that doesn't answer your question. I'll revisit the
>>> documentation to try and incorporate the additional information in the
>>> issue.
>>
>> Yes, thank you.
> 
> As regards the above problem, I've been able to find the problem, but I
> had to read the code. The problem is in
> 
> app/Jobs/FetchFilteredPrefixesForCustomer.php
> 
> where, in line 116, the form of the name of the protocol is hardcoded to
> what INEX uses. Naturally, in GR-IX we use different names (indeed our
> entire Bird configuration is considerably different than the example in
> IXP Manager)

Ah, well, I'm afraid that was never going to work then :-(

This tool - as well as many others in the IXP Manager / IXP Manager 
route server configuration system are tightly coupled.

We would encourage IXP Manager users to use the IXP Manager route server 
configuration in so far as possible. I would also be interested to learn 
why you're not using it and what you've done differently to see if we 
can improve what we ship with.

> Worse still, some form of caching may be involved, which I have
> been able to circumvent by invoking the artisan router:filtered-prefixes
> command via the cli.

There is definitely caching involved here and for two reasons:

1. to rate limit the number of queries end users can direct to the Bird 
daemons. For larger route server peers, these look ups can be expensive.

2. Again, for larger users, we have to ensure the web request doesn't 
time out. So the job of getting the prefixes can be queued, the results 
cached and the user asked to check back in 'x mins' to get the results.

  - Barry