[120150] in North American Network Operators' Group
Re: More ASN collissions
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Dec 10 18:22:01 2009
Date: Thu, 10 Dec 2009 15:21:19 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch =
wrote:
> As always, good research by renesys.
>=20
> 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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBSyGCb7N3O8aJIdTMAQLkgg/9HqW3Vk0rgUvNeXsB2VzvSkpe7wnX7MJ1
kSumLXaOzRSZxyjHI34vYd5ext8OhSMBW04jLe+p+fJVKDKNR2yX5CWzqetmtK3e
mEdulIbZXC3kS+HzBtt/L8S1ba4xOQtctQakrWRz9Td7PyEnyk43Rv66eR8qmqTc
kHsRvVn/NzdQCs4Qhebs/gYH2NIh2BqgbmobY+XL2J80rQDPAes+9+71omwLRqQ1
dKfOtxtBWr/NCb/uMmggrQCgo7Yt8YCTWUwHcsUEIoiDnzj3uZU23bkXEz306dd9
I7iXhe5ZzTXvWpqnm1YmP4ziBhVXCM8+FMhBiDGeowYlZ77BmqKlAa5tDzjjRYc+
Hs1XuW36yt8crKeXvcHSMogWFZVZDcXIAb7jtMJu0lOSyodHFngMObHbZS3c0RUA
hOuO5RnhSq2l+va1TcyZWcGCGSlzObIGeaTMsWNiLeHaIT8Esi5AasxBfgm3m5nO
IG4md7vA3uQiX6e6tU1aqCo3uzRiESl8YF8LByzgTe0IPWHdcJgyt16fY2actQF6
bVxCUzlualsFWux68asUQtfzYpJwihUrOonyRE5xMhy7Ea9MDZTm/So1UO4GI4MS
Au8MPUBGEZdkAFko288o0BMS1dk/3vMfE8ozv6RY+02RFWKWwiTkjBOHRw3Uxw80
L4i7A2aXrBI=
=WU/V
-----END PGP SIGNATURE-----
--h31gzZEtNLTqOjlF--
