December 2002 - Test - lists.nanog.org

Operational Issues with 69.0.0.0/8...
by Todd A. Blank 02 Dec '02

02 Dec '02

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

1 0

Re: Federal Reserve Risks Collapse Re: Risk of Internet collapse grows
by sgorman1＠gmu.edu 01 Dec '02

01 Dec '02

The validity of the data and assumptions made in the Grubesic paper is not the topic I intended to discuss, I did not write the paper and I am not the person that can answer questions or criticisms. I can sympathize with the difficulties of getting good data for the analysis that was endevoured, and the problems of publishing timely results. We found similar problems with the Boardwatch data (well noted in several posts) when doing related analysis, but I do believe that the paper does make an interesting contribution with the techniques it used - different from the assumptions and data. This is probably the biggest disconnect between the academic and operations community, in academia a greater value is placed on the analytice techniques created, and the data is a means to test those techniques or tools. What happens outside the ivory tower is often an after thought. This is a very general statement and varies considerably by discipline. Regardless it becomes a problem when real world data is being used to inform the policy creation process. This is the unusual situation we find ourselves in, and any and all feedback, commentary, and discussion is very valuable even flames. Hopefully we have a chance to get some in person come the February meeting. This thread has pointed out the pitfalls of research, but it would be interesting to discuss ways that cooperative efforts could be built to avoid these pitfalls. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Saturday, November 30, 2002 6:04 am Subject: Re: Federal Reserve Risks Collapse Re: Risk of Internet collapse grows > On Fri, 29 Nov 2002 sgorman1(a)gmu.edu wrote: > > What you decided to attack on the post was the defense of another > > researchers options of data and how current that data was. He used > > what was available to him at the time, end of statement. > > As long-time readers (or anyone with access to Google) know, > Boardwatch'sISP Directory as a data source has a long history of > problems going back > to the mid 1990's. It has been extensively discussed on this and > many,many other ISP mailing lists in the past. > > When you have limited or poor quality data, you need to be even more > careful about what conclusions you make. > > > If you could you use your expertise and creativity to help the > > research community produce better research instead of shooting > > everything down after the fact, something postitive might actually > > come from the effort. > > I have. > > If researchers are going to use Boardwatch's ISP Directory as a data > source, treat it like any other advertising directory (e.g. the Yellow > Pages). It is a poor source for engineering technical data. Its > a great source for comparing advertising budgets, marketing campaigns, > finding sales departments. > > >

1 0

question concerning traceroute?
by Darrell Carley 01 Dec '02

01 Dec '02

I am trying to troubleshoot a latency issue for some of our networks, and was wondering about this.Knowing that routing isn't always symmetrical, is it possible for a traceroute to traverse a different reverse path, than the path that it took to get there? .or will it provide a trace of the path the packet took to reach the destination? According to definition, is should take the same path, but are there any other cases that I should be aware of? Darrell

24 34