Well Jon, I spent some time reading your message below, and trying to look at if I experienced the issue, just what I would have done differently, or what would have been more meaningful in your initial email blast... Here are some of my thoughts... First since you are taking the time to explore where your routes are reaching, why not send the end user (yes your approach contacts the end user of the IP addres block not the network provider) a traceroute showing where the problem is first encountered? Now granted some places may filter ICMP messages, but it is some more information from which the end user can start addressing the problem? Next I would suggest that you look at the tone of your message to make sure that the reader understands that you have an issue and that you would like his assistance. Sometimes emails can be viewed as HARSH when they are meant to be informative and helpful in getting the issue corrected. I would personally have run a traceroute with the NANOG traceroute and also copied the Network ASN where the packets seems to have stopped. After all that is the most likely source of the filter, right? When I received your original message that is the first think that I did from an off network account. You mention that we should update our ARIN listing... well I do not disagree, but the subnet where the packets stopped would have had a noc email with 24x7 number to call. Then again so would have the ASN where the traceroute stopped. Yes I think that there is interest in understanding new subnet allocations have universal routing. Clearly in this case when addressing was first allocted in Aug 2002 this should have become and issue by now... You suggest that ARIN should do more (lets expand this to any RR), what would you suggest they do? Do you plan to be at the ARIN meeting in April? We would welcome your views on this topic be addressed... Take it to a ARIN advisory council member if you do not plan to attend, they can champion your cause... they do it well... On Mon, 10 Mar 2003 jlewis@lewis.org wrote:
On Mon, 10 Mar 2003, Michael Whisenant wrote:
First I appreciate your message that you sent to us at NASA late Friday regarding a new address block that you received from ARIN. In that message you suggest that the issue was a BOGON route filter that had not been updated. Then without allowing sufficient time to respond to your message (you sent it to an administrative account and not the NOC) you decided to flame NASA.
My mention of NASA wasn't meant at all as a flame. It was just an example that not all the networks with outdated filters are remote nets in far away countries that my customers wouldn't care about. A few I've found are. I had to look up the country code to find that .al is Albania.
I had actually planned to mention at some point that NASA was the first (only so far) network to respond to the few messages I sent out late last friday, and that their reported network has already been fixed. I can only assume that none of the previous 94 allocation holders of 69/8 space noticed or complained to the right people.
If you feel that you have any issue reaching a NASA resource then you can send a message to noc@nisn.nasa.gov and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space.
As for sending the message to the wrong addresses, I can only suggest updating your ARIN info. I sent the message to all the POCs (except the abuse one) for the relevant NetRange. This is what I'll be doing when I send out the automated messages. The ones sent friday were done by hand.
Can you elaborate on how a firewall config was the problem? If whatever was done there is commonly done, it may be worth revising my form message before I send out a large number of them.
---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________