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:
Thanks for the reply, James.
I wish I could tell you the answer. We see traffic passing through some of the routers (transit), but on each network, or their downstreams there seem to be different devices filtering. Sometimes it is a border or peering router. In other cases, it has been access devices, such as firewalls.
One we resolved this morning (with some help from the good folks at ARIN) was a downstream provider from one of these transit providers that was filtering in their devices as well.
I am just trying to raise general awareness that the 69.0.0.0/8 block is assigned and out there in use, and to get people to re-examine their filters, access lists, etc.
You help and response is appreciated.
Sincerely,
Todd A. Blank 614.207.5853
-----Original Message----- From: Feger, James [mailto:jfeger@feger.net] Sent: Monday, December 02, 2002 1:35 PM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8...
When you say 'Networks involved' do you mean those providers are blocking the traffic, or you see these networks in the transit?
Thanks, James
On Mon, 2 Dec 2002, Todd A. Blank wrote:
To all concerned:
We have been assigned a CIDR of 69.1.192.0/19.
We have had numerous problems getting traffic through to various
destinations.
We are finding that many routers are still filtering 69.0.0.0/8.
This block used to be restricted, but was assigned by IANA to ARIN in
August of 2002.
If anyone is still filtering this block in their routers, please
remove the filters!
Here are some of the destinations that are not reachable if your
source is anywhere in the 69.0.0.0/8 CIDR:
www.cplink2.com www.ocas.com www.indofilms.com www.lavalife.com
Some of the Networks involved are Cable and Wireless, Allegiance
Internet and AT&T.
Thank you,
Todd A. Blank IPOutlet LLC 614.207.5853
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