[ixpmanager] question re: compare-route-server-prefixes.pl

[Andreas Polyrakis]

Hello Barry,

On 07/18/2017 10:31 AM, Barry O'Donovan wrote:
> Created this issue out of this conversation:
>
> https://github.com/inex/IXP-Manager/issues/329
>
>   - Barry
>
> Barry O'Donovan wrote:
>> Athanasios Douitsis wrote:
>>> We were having a discussion with Andreas, which boiled down to the
>>> question of why the
>>> tools/runtime/route-servers/compare-route-server-prefixes.pl script
>>> needs to access the Bird configuration file instead of querying the Bird
>>> daemon directly. What we mean is that, since the configuration dictates
>>> which prefix is eventually accepted or not, one might as well query the
>>> master routing table directly from Bird and see which prefixes present
>>> in the t_$vliidhash{ $asn } made it through. The rest of the logic
>>> remains more or less the same, prefixes not accepted have irrdb 0,
>>> accepted have 1, etc.
>> There are three data points we are interested in:
>>
>> 1) advertised and accepted
>> 2) advertised and not accepted
>> 3) not advertised but acceptable
>>
>> (1) is easy as we learn from Bird if the prefix is advertised and based
>> on config will know that it's accepted.
>>
>> NB: presence in the master table is not an indication of (1) for the
>> peer under consideration. Larger members can and often do transit for
>> smaller members.
Can you elaborate a little bit on this? I cannot understand how 
something can be present in the master table but not "advertised and 
accepted".
>> (2) is identified the same way as one but by omission from the
>> configuration.
To add some context on the problem:

At some point we modified our (test) bird configuration to accept more 
specific prefixes. I.e, instead of 10.0.0/8, the configuration file 
contained 10.0.0.0/8+. After this change, the (unmodified) script would 
still categorize 10.0.0.8/24 as "advertised but not accepted"; although 
it was actually accepted.

At that point we realized parsing the config files can sometimes be 
tricky and give results that differ from reality (eg the example already 
given, misconfiguration in filters (eg not correctly applied), route 
server bugs etc). It might make more sense to calculate this bases on 
queries on the route daemon.

>>
>> (3) is identified based on presence in the configuration but absence
>> from the member's advertised routes.
>>
>> So, to answer you specific question: (1) and (2) need access to the
>> configuration.
>>
>>> If there are any comments on this (Barry?), we would be delighted to
>>> hear, er, read them. At GR-IX we use a slightly modified version of that
>>> script, but we could conceivably make some contribution back to the
>>> original one. But we'd like some opinions on whether this makes sense or
>>> if there's something we are missing.
>> The medium term plan is to lose this script as there are a number of
>> issues with it:
>>
>> 1) using this, the Route Server Prefix Analysis Tool is limited to a
>> single route server (we have three peering LANs with two route servers
>> each);
>>
>> 2) the validity of the tool is for a state 'sometime in the past ~6
>> hours'; i.e. whenever the tool last ran. This sometimes leads to
>> confusion for diagnosing real time issues.
>>
>> Now that we have Birdseye, we can make this tool realtime and against
>> any of the targeted six route servers.
>>
>> The main issue we need to bear in mind (note to self) is what happens if
>> the configuration is out of sync with the database as a tool using
>> Birdseye will not have access to the config. However, it will know the
>> last time a route server was updated.
Ok, that makes sense. However it is not easy with birdseye to query for 
filtered prefixes. Do you plan to add such functionality?

Andreas
>>
>>   - Barry
>>
>>
>>
>>
>> _______________________________________________
>> INEX IXP Manager mailing list
>> ixpmanager at inex.ie
>> https://www.inex.ie/mailman/listinfo/ixpmanager


-- 
-----------------------------------------------------------------------
Andreas Polyrakis - apolyr at noc.grnet.gr
GRNET NOC Technical Manager
Greek Research & Technology Network - http://www.grnet.gr
7, Kifisias Av., 11523 Athens, Greece
Mobile: +30 6972832445    Office: +30 2107474249   Fax: +30 2107474490
-----------------------------------------------------------------------