[6242] in North American Network Operators' Group
Re: IRR
daemon@ATHENA.MIT.EDU (Curtis Villamizar)
Wed Nov 20 22:25:38 1996
To: labovit@merit.edu
cc: Brian Merritt <bmerritt@asdf.getnet.com>, nanog@merit.edu
Reply-To: curtis@ans.net
In-reply-to: Your message of "Mon, 18 Nov 1996 13:59:45 EST."
<199611181859.NAA09628@merit.edu>
Date: Wed, 20 Nov 1996 22:23:20 -0500
From: Curtis Villamizar <curtis@ans.net>
In message <199611181859.NAA09628@merit.edu>, Craig Labovitz writes:
>
> We don't have numbers for the number of unique routing table entries that hav
> e
> IRR origin discrepancies, bit it might be useful to look at a chart of some o
> f
> the larger providers. With the exception of Sprint, most providers seem to
> have ~10% error in their BGP announcements (of course, this is from a very
> small sampling).
>
> (Data from 11/18/96)
> Provider #RT entries #discrep %
> --------------------------------------------
> ANS 2611 186 7.13
> Advantis 183 21 11.47
> BBN 8996 1129 12.55
> Compuserve 1523 3 .20
> MCI 15135 1578 10.43
> SPRINT 14085 3584 25.45
> UUNet (no information available)
I just looked through:
http://compute.merit.edu/stats/mae-west/problems/IRR/1673.961119.html
Of the 192, in 54 the registered origin AS was in the AS path, but was
not the origin AS. This is common. The provider registers the route
object using the provider's AS rather the true origin AS. In some of
these cases the prefix is dual homed to two ANS AS and only registered
in one with policy set to accept either. One was deleted from the IRR
and replaced with an aggregate but our configs haven't picked upthe
change and two were listed in the Merit report as AS0, but there were
IRR entries for those with the correct origin. I spot checked a bunch
of others (208.141.24.0/22, 208.141.16.0/21, 207.166.192.0/19,
207.70.114.0/24) and there were route objects corresponding to the
origin AS so there is also a problem with the reporting where there
are false errors being listed.
Curtis
