[ixpmanager] (no subject)

[Nick Hilliard]

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 <mailto:edd at edd.za.net>
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20180811/19068835/attachment.html>