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

Barry O'Donovan barry.odonovan at inex.ie
Tue Jul 18 08:31:57 IST 2017


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.
> 
> (2) is identified the same way as one but by omission from the
> configuration.
> 
> (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.
> 
>  - 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



More information about the ixpmanager mailing list