More ASN collissions

Thu Dec 10 23:21:19 UTC 2009

In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote:
> As always, good research by renesys.
> 
> http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml

As already commented on the blog...

ISC had a data entry error on an ASN for our site in Fiji.  There
was no RIR mixup, it was purely an error on our part.  This was
then further propogated when scripts we had generated routing
registry objects and pushed them out.

We're already down the path of fixing it, and the error will be
corrected soon.  We would like to thank Renesys for bringing it to
our attention.

While the ARIN / RIPE mixup in the 17xx range has caused a lot of
people to go looking for a smoking gun I think Renesys has proved
there is in fact no cause for alarm.  40,000+ ASN's in use and only
two for which there is even a question.  0.005's of a percent error
rate in a global system is quite good.

To also answer one of the questions posed in the blog.  It is only
recently (I think about 4 months ago) ISC fully scripted it's routing
registry updates, which is what caused the AS35686 to ISC entry in
the RIPE DB.  Prior to that there would have been no ISC entry
anywhere, as it was not assigned to ISC; thus no other party would
have checked it.  I can't comment on if ISC checked if the ASN was
in the APNIC database properly when they received it or not, but
noting it was a data entry typo it is entirely likely the database
was checked with the proper ASN, and then the data was miss-entered
into internal systems.

I would be very interested to know if something similar happened
with AS3745.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091210/bc75e3a1/attachment.sig>