Re: Operational Issues with 69.0.0.0/8...

Todd, If this helps. Do something like the following... telnet route-views.oregon-ix.net > /tmp/file term len 0 sh ip bgp 69.0.0.0 255.0.0.0 l quit cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more ...your commands will vary. You will see plenty of routes within 69/8. A closer look with show that around 121 routes are seen in the 69/8 range via most of the feeds into Oregon. There is one big exception... 69.4.64.0/20 ... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route within 69/8 that shows up via AS-2548. This is valuable information. It does not mean there is filtering within AS-2548, but I would recommend you contact them to further this investigation. BTW: This is exactly what Oregon is great for! It shows up issues like this with ease. Thanks! Martin --------------------------- At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote:

This topic came up on cisco-nsp, but was really more appropriate here. Been meaning to post summaries when I got enough round tuits. A suggestion was made there that the RIRs give a bgp feed of 'unused' routes to interested parties such that they can be blackholed, etc. Sounded like a lot of overhead and things which could go wrong to me. Skipping over the arguments about who would/wouldn't modify processes and would take such a feed, I wouldn't want to have to pay for that infrastructure, its support and maintenance out of my regsitry fees. I do think it makes LOADS of sense to have the (un)allocations clearly visible in the IRR. Some of the RIRs do it today for their 'greater aggregates' [eg, whois -h whois.ripe.net 82.0.0.0/8]. Sure, you'd still have providers ignoring the IRR, but it gets a lot harder for them to whine about the time it takes to update filters or the lack of automation if the data is in a standard format in globally distributed DBs for which there are umpty public tools. There's always the gripe about authentication. Perhaps the IANA should set up a routing registry which merely publishes in RPSL format the allocated/unallocated list (http://www.iana.org/assignments/ipv4-address-space) and the truly paranoid can just consult *only* that registry for their configuration magic? That would be a one-time hit for IANA [or volunteers] to make the flat-file-to-RPSL code, and being a single- source could be cyptographically signed/confirmed if needed. Cheers, Joe -- crimson@sidehack.gweep.net * jprovo@gnu.ai.mit.edu * jzp@rsuc.gweep.net RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
participants (2)
-
Joe Provo
-
Martin J. Levy