% whois -h whois.ripe.net AS1712
aut-num: AS1712
as-name: FR-RENATER-ENST
descr: Ecole Nationale Superieure des Telecommunications,
descr: Paris, France.
descr: FR
% whois -h whois.arin.net AS1712
OrgName: Twilight Communications
City: Wallis
StateProv: TX
Country: US
And, yes, AS 1712 is actually used by both and announced 
Looks like FR-RENATER-ENST is in the wrong:
1708-1728 Assigned by ARIN whois.arin.net
(source: http://www.iana.org/assignments/as-numbers/ )
Jeff
a message of 42 lines which said:
Looks like FR-RENATER-ENST is in the wrong:
You mean RIPE-NCC is wrong? Because this AS is used by ENST for many
years and is registered in the RIPE database...
* Jeffrey Lyon:
Looks like FR-RENATER-ENST is in the wrong:
1708-1728 Assigned by ARIN whois.arin.net
(source: Autonomous System (AS) Numbers )
It could have been ERXed (or whatever the process is called for AS
numbers).
% whois -h whois.ripe.net AS1712
> as-name: FR-RENATER-ENST
>
> % whois -h whois.arin.net AS1712
> OrgName: Twilight Communications
That would be ARIN, rather than RIPE:
http://www.iana.org/assignments/as-numbers/as-numbers.xml
"1708-1728 Assigned by ARIN whois.arin.net"
> And, yes, AS 1712 is actually used by both and announced 
Ouch, that's unfortunate.
-Bill
at least they are protected from eachother...
In all seriousness though, how does this get fixed? and... who has to
renumber? 
Bill Woodcock wrote:
The RENATER I'm peering with is AS2200.
respect do to them I doubt their announcing RENATER.
From what I receive from as2200:
* 137.194.0.0 194.68.129.102 0 2200 2200 2422 1712 i
And from bgp table (sniped):
sh ip bgp path 1712$
Address Hash Refcount Metric Path
0x52D8F878 352 2 1001 174 1712 i
0x575A9088 1320 1 0 6453 174 1712 i
0x2274494C 1849 2 0 6453 701 1712 ?
0x52CF7AD0 1986 1 0 2200 2200 2422 1712 i
0x66B90AD0 3421 1 0 2200 2422 1712 i
Indeed: WTF.
Stephane Bortzmeyer a �crit :
Arin CREATE DATE:
2009-08-19
RIPE CREATE DATE:
1999-10-14
well, we all know the serious of these compagny....
@+
a message of 36 lines which said:
The RENATER I'm peering with is AS2200.
The AS number was allocated (ten years ago, as noticed by Fr�d�ric)
through the LIR Renater to the customer ENST (now T�l�com Paris
Tech). It does not mean it is today announced by Renater.
a message of 29 lines which said:
it appears that AS1708-AS1726 were missed and have subsequently been
reallocated by ARIN (between Aug 18 and Aug 21, 2009)
Now, interesting question: what can we do to solve the problem? Who
should act?
I am quite surprised that it is possible to have the same AS number in
two different RIRs, to different organizations IP resources
certificates will be difficult to deploy here.
oh! we can test out that 'transfer' policy now! lookie it's the
ip-resources grey market arriving early (or on-time, depending upon
which of Geoff's presentations you read over the years)
-Chris
So much so that they probably can't even email each other to discuss it...
--Steve Bellovin, http://www.cs.columbia.edu/~smb
>> Ouch, that's unfortunate.
>
> at least they are protected from eachother...So much so that they probably can't even email each other to discuss it...
--Steve Bellovin, http://www.cs.columbia.edu/~smb<http://www.cs.columbia.edu/~smb>
Well, unless they have default routes... 
It's not just AS1712. AS1707 - AS1726 appear to all have been
allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it
appears that AS1708-AS1726 were missed and have subsequently been
reallocated by ARIN (between Aug 18 and Aug 21, 2009)
this failure is one of the joys of per-rir trust anchors
randy
In all seriousness though, how does this get fixed? and... who has to
renumber?
luckily, it's not a renumber in the ip address sense. but some router
jock[ette]s are gonna be even more overworked than usual.
how to detect if there are more instances?
how to prevent new instances, both asn and ip?
randy
The whole value of the RIR is to guarantee this uniqueness. This problem
should not have happened.
The fact that it has is troublesome. I¹ll make a guess that this is a result
of a clerical error somewhere in the chain...
The answer to the above question seems to be stricter process.
- Alain.
The answer to the above question seems to be stricter process.
mops schmops. formal rigor and tools, please.
randy
I don't see operators jumping at the idea of central trust anchor
myself, no more than I see everyone ready to sign the root zone.
I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD
operators want it signed. There is perhaps the same issue here.
Then again, ARIN doesn't say that an allocated resource is actually
usable, they've specifically ducked that one in the past with address
space on blacklists or bogon filters... I am curious to see their response
now.
- Jared
Even after that clerical error happened, the subsequent error of assigning an ASN that's already assigned should never have happened. It seems someone (probably multiple someones) never considered this possibility.
When assigning a subnet of our IP space to a customer or internal network, first I look for a suitably sized block marked as "open" in our IP space. Then I check our IGP to make sure that block isn't currently routed somewhere. It's a little disappointing that I ever find it is...but it happens. It just happened yesterday in fact. A customer who had some servers turned down had their subnet marked as available for re-use, but it looks like they still have a few servers online in that VLAN and the space obviously isn't ready for re-use.
Is it too much to ask that the RIRs query each other's whois servers for an ASN before assigning that ASN?...just to make sure an ASN they think they're responsible for and about to assign hasn't already been assigned by another RIR? That should have been an item on the RIR ASN assignment checklist from the beginning.