[ixpmanager] route server prefixes

Mon Aug 13 11:22:24 IST 2018

Edrich de Lange wrote on 12/08/2018 19:27:
>   So, Nishal helped me pinpoint it to the fact that we allow more
> specifics, and with us doing that, it ends up not matching anything
> (as the initial regex doesnt match anymore)

yeah, this is an issue with the perl script since we added the more 
specifics functionality.

we're hoping to update the perl script when our resident perl expert has 
some spare cycles.

  - Barry

> 
> So as a temp work around, I made this modification to the script, to
> just ingnore the {22,23} Etc.
> 
> 117c117
> < if (/^\s*allnet\s*=\s*\[\s*([a-fA-F0-9\.:,\s\/]+)\s*\]/) {
> ---
>> if (/^\s*allnet\s*=\s*\[\s*([a-fA-F0-9\{\}\.:,\s\/]+)\s*\]/) {
> 119a120
>> $prefixes =~ s/{[^}]*}//g;
> 
> 
> Im hoping there is a better fix than this? As obviously it doesnt
> match the routers which are more specific. (This does mean I can beat
> some people with a pointy stick and get people to correct their irr
> entries)
> 
> I know there is a Feature outstanding for this to be rewritten.
> https://github.com/inex/IXP-Manager/issues/235 /
> https://github.com/inex/IXP-Manager/issues/329
> 
> But they are a smidge old :-)
> 
> 
> Kind regards
> Edrich de Lange
> edd at edd.za.net
> 0832629566
> 
> On Sat, Aug 11, 2018 at 6:00 PM Nick Hilliard <nick at inex.ie> wrote:
>>
>> Hi Edd,
>>
>> This mechanism is a bit involved, but the way it works is as follows:
>>
>> each customer is set up with an IRRDB policy in the customer setup page.  You need to select one of the existing policies which pulls prefixes with the appropriate source: list from either RADB or else from the RIR-operated IRRDB.  Each customer can be set up with their own unique policy, so you need to check out what works best for them.
>> when you issue the 'artisan irrdb:update-prefix-db' and 'artisan irrdb:update-asn-db', this pulls information from the per-customer IRRDB sources into the IXP Manager SQL database.
>> 'compare-route-server-prefixes.pl' inspects what BIRD sees incoming from each client connection and compares that against what it finds in the IXP-M SQL DB.  If it doesn't find a match, it prints: "irrdb:0" because that indicates that it couldn't find that specific prefix in the IRRDB output for that customer.
>>
>> To resolve your problem you need to find out what IRRDB holds the definition for AS-THUSACONNECT and configure that as the IRRDB source for your member in IXP Manager.  Once you've done this, you should run artisan irrdb:update-prefix-db and see if it picks up that particular /32.  If this doesn't solve the problem, there's something more involved going on, but try this first and see how it goes.
>>
>> Nick
>>
>> Edrich de Lange
>> 7 August 2018 at 13:42
>> Hi All
>>
>> We are having some difficulty using the route server prefixes
>> functionality with compare-route-server-prefixes.pl and thought it would
>> be wise to see if there was something obvious that we were missing.
>>
>> We’ve converted one set of our route servers to use the ixpmanagers
>> generated configs for bird, and that’s working fine. The
>> compare-route-server-prefixes.pl script correctly pulls in the routes
>> being advertised. But it thinks that 99% of these are not accepted (it
>> does show some as accepted, and some not advertised but accepted)
>> according to the frontend. (Meanwhile, at route-server level, the
>> actual routes are being accepted, processed the route-server filters,
>> and propagated onwards correctly)
>>
>> My perl is really sucky, so debugging this is also a bit difficult. :-)
>> I can see it inserting the routes into the DB, all fine, but the routes
>> most get listed as “accepted but filtered” as opposed to “accepted
>> and advertised”
>>
>> Debug output :
>> INSERT: peer-as: xxxxx, prefix: x.x.x.x/x origin-as: xxxx, irrdb: 0
>>
>> Im assuming the irrdb:0 is what determines if its filtered or not. But I
>> can not figure out where that data comes from. Out of about 50 000
>> routes, there is about 15 that it says is accepted. (which is obviously
>> incorrect).
>>
>> I have installed the perl libraries required, and I see no other errors
>> from the script. It sees all the peers, along with their announcements.
>> And if I run the command manually, it seems to be correct output:
>>
>> root at rs2:~#  /usr/sbin/birdc -s /run/bird/bird6.ctl show route table
>> t_0130_as32437 protocol pb_0130_as32437
>> BIRD 1.6.3 ready.
>> 2c0f:f178::/32     via 2001:43f8:1f0::121 on eth1
>> [pb_0130_as32437 21:09:48] * (100) [AS32437i]
>>
>> And that prefix is definitely in the irrdb record
>> root at rs2:~# bgpq3 -b -6 as-thusaconnect
>> NN = [
>> 2c0f:f178::/32
>> ] ;
>>
>> Cluebat anyone?
>>
>> Edd
>>
>> edd at edd.za.net
>> 0832629566
>> _______________________________________________
>> INEX IXP Manager mailing list
>> ixpmanager at inex.ie
>> Unsubscribe or change options here: https://www.inex.ie/mailman/listinfo/ixpmanager
>>
>>
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> Unsubscribe or change options here: https://www.inex.ie/mailman/listinfo/ixpmanager
> 

-- 

Kind regards,
Barry O'Donovan
INEX Operations

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