More ASN collissions
bicknell at ufp.org
Thu Dec 10 17:21:19 CST 2009
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote:
> As always, good research by renesys.
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
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
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
Size: 826 bytes
Desc: not available
More information about the NANOG