On Wed, 22 Jun 2005, Geoff Huston wrote: One potential problem: ERX data. I am looking at all the Israeli entries for example, from 192.114.x.x-192.118.x.x You will find it in RIPE whois, but you won't find it in the RIPE stats file since the block was ERXed as were probably many others. Not sure how you can handle that. Regards, Hank
cleared up BUT changed in one important respect:
If an entry isin the RIPE whois database but NOT in the RIPE stats file I'm marking it as potentially bogus. I would like to see the RIPE stats file be an accurate picture of RIPE managed address space, and the database is completely unreliable :-(
Geoff
At 01:08 AM 18/06/2005, Hank Nussbacher wrote:
I was hoping the report would be cleaned up by now but it hasn't so sorry for the multiple list post. The Bogon section is IMHO, broken.
Taking just the 1st line as an example: Prefix Origin AS AS Description Unallocated block 3.0.0.0/8 AS80 GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0
3.0.0.0/8 is allocated, as is AS80. I suspect the algorithm, which determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat broken.
There are thousands of lines like that.
The bogus AS section also appears to be broken.
-Hank
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Hank Nussbacher wrote:
On Wed, 22 Jun 2005, Geoff Huston wrote:
One potential problem: ERX data. I am looking at all the Israeli entries for example, from 192.114.x.x-192.118.x.x
You will find it in RIPE whois, but you won't find it in the RIPE stats file since the block was ERXed as were probably many others.
Not sure how you can handle that.
Hank, Most of the ERX networks are in the reg files. There were a few conflicts (5 in 192.0.0.0/8) that did not import properly due to overlaps with other data. I'll have someone in the RS department contact the appropriate folks and get this sorted out. Apologies for this. -- Shane
On Wed, 22 Jun 2005, Shane Kerr wrote:
Hank Nussbacher wrote:
On Wed, 22 Jun 2005, Geoff Huston wrote:
One potential problem: ERX data. I am looking at all the Israeli entries for example, from 192.114.x.x-192.118.x.x
You will find it in RIPE whois, but you won't find it in the RIPE stats file since the block was ERXed as were probably many others.
Not sure how you can handle that.
Hank,
Most of the ERX networks are in the reg files. There were a few conflicts (5 in 192.0.0.0/8) that did not import properly due to overlaps with other data.
From: http://bgp.potaroo.net/cidr/ it looks like something is also wrong with 193.0.0.0/10 range. -Hank
I'll have someone in the RS department contact the appropriate folks and get this sorted out. Apologies for this.
-- Shane
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
I used the term "completely unreliable" as an unwarranted exaggeration - my apologies. However there are some obvious incorrect entries in the RIPE database such as entries for BT-NORTH-BLOCK-CAMBRIDGE inetnum: 2.6.190.56 - 2.6.190.63 2.6.190.56/29 SE-MARINEX inetnum: 5.163.66.80 - 5.163.66.95 5.163.66.80/28 Such entries as those above are easy to spot simply because they refer to prefixes from /8 address blocks that are in the IANA reserved pool. Unfortunately this raises the larger question of whether there are similar erroneous entries in address blocks that are part of the RIR-allocated address block pool, and at this stage I have no way of making a clear call here. In this report I've erred on the basis of high caution. Perhaps it would be more useful in terms of listing potential bogons to accept the RIPE database entries as allocated even where there is no corresponding stats file entry (blocks that appear to have been transferred via ERX, for example). thanks, Geoff At 01:27 AM 23/06/2005, Hank Nussbacher wrote:
On Wed, 22 Jun 2005, Geoff Huston wrote:
One potential problem: ERX data. I am looking at all the Israeli entries for example, from 192.114.x.x-192.118.x.x
You will find it in RIPE whois, but you won't find it in the RIPE stats file since the block was ERXed as were probably many others.
Not sure how you can handle that.
Regards, Hank
cleared up BUT changed in one important respect:
If an entry isin the RIPE whois database but NOT in the RIPE stats file I'm marking it as potentially bogus. I would like to see the RIPE stats file be an accurate picture of RIPE managed address space, and the database is completely unreliable :-(
Geoff
At 01:08 AM 18/06/2005, Hank Nussbacher wrote:
I was hoping the report would be cleaned up by now but it hasn't so sorry for the multiple list post. The Bogon section is IMHO, broken.
Taking just the 1st line as an example: Prefix Origin AS AS Description Unallocated block 3.0.0.0/8 AS80 GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0
3.0.0.0/8 is allocated, as is AS80. I suspect the algorithm, which determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat broken.
There are thousands of lines like that.
The bogus AS section also appears to be broken.
-Hank
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
participants (3)
-
Geoff Huston -
Hank Nussbacher -
Shane Kerr