- NANOG - lists.nanog.org

Re: Alpha test of MAE filtering capability
by Chris A. Icide 31 Jan '97

31 Jan '97

At 07:49 PM 1/30/97 -0500, Matthew E. Pearson wrote: > >Or you could just your the RADB Route Servers like a reasonable ISP :) > > Dear Mr. Pearson, I just noticed a message right before this from Stan Barber, directing people to a search engine for NANOG notes. I suggest that you hop on that site and search from something like "default route", "peering" (which ought to be fun to read anyway), and maybe "peering abuse" or something like that. In fact, you may want to browse through the entire site, and become familiar with the last NANOG before you go jumping around and sticking your foot in your mouth. However, you are most likely a busy person, so I'll graciously pass on my thoughts (having attended the most recent NANOG meeting in A2), concerning Mr. Feldman's announcement. During that NANOG, concern was expressed over the ease of abusing the exchange point by pointing a default route at any member of that exchange point. Obviously this only works on an exchange point where any entity can reach any other entity whether or not a peering agreement exists (a feature pointed out by our friends at the ATM NAP's). The solution that Mr. Feldman allows us to at least eliminate possible abuse from non peers. If a peer chooses to commit such abuse, one can just terminate the peering session, a stiff penalty in our current times (considering the increasing difficulty of obtaining valuable peering agreements), and add that entities IP address to the above mentioned filter list on the exhange point switch. We, who were recently a victim of such abuse, will definately use this feature as soon as it is made available. Thank you for your patience while reading my take (and this is only my take) on this subject. Hope to see you at the next NANOG on Feb 10th & 11th. Chris A. Icide Nap.Net, L.L.C.

3 3

Re: Just from curiosity.... (fwd)
by Josh Gilliam 31 Jan '97

31 Jan '97

traceroute (the original), which is maintained by Lawrence Berkeley National Laboratory, already supports this and can be obtained from ftp://ftp.ee.lbl.gov/traceroute-1.4a4.tar.Z (Jan 7 1997). Josh Gilliam -- soil(a)quick.net On Wed, 29 Jan 1997 17:20:30 +0000 (GMT), in message <199701291720.RAA18152(a)alice.wonderland.org>, Peter Galbavy wrote: > This change (and any other new ICMP messages) might be worth incorporating > into the standard traceroute... > > Forwarded message: > > From owner-nanog(a)merit.edu Sat Jan 18 19:35:50 1997 > > Date: Sat, 18 Jan 1997 08:55:31 -0700 (MST) > > From: Ehud Gavron <GAVRON(a)ACES.COM> > > Subject: Re: Just from curiosity.... > > In-reply-to: "Your message dated Fri, 17 Jan 1997 18:21:36 -0500" > > <199701172321.SAA22758(a)widderhen.reston.mci.net> > > To: roy alcala <roy(a)mci.net> > > Cc: Brian Tackett <cym(a)acrux.net>, nanog(a)merit.edu, > > Rob Barron <rbarron(a)acrux.net>, GAVRON(a)ACES.COM > > Message-id: <01IECPNYCFYC8WXTGM(a)ACES.COM> > > Organization: ACES Research Inc. > > MIME-version: 1.0 > > Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > References: <Pine.GSO.3.93.970117162448.21258A-100000@pluto> > > Sender: owner-nanog(a)merit.edu > > > > ftp://ftp.aces.com/software/traceroute/traceroute_new.c > > ftp://ftp.aces.com/software/traceroute/0_readme.txt > > > > This BETA version incorporates two new changes: > > 1: It will show a !A for administratively-prohibited packets (see below) > > 2: It will allow modification of a line terminator from standard <LF> > > to anything else, allowing, for instance, dynamic access from > > web browsers (see www.opus1.com/www/traceroute.html) > > > > Feel free to test. > > > > Ehud > > > > > > > > > > >You see this behavior because your traceroute program does not > > >understand the ICMP "administratively prohibited" (ICMP type 3, code > > >13 - defined in RFC 1812) messages being sent back to it from > > >cpe1.reston.mci.net. > > > > >Cisco routers typically return ICMP messages of this nature to the > > >source of traffic which is being blocked by a traffic-filtering > > >ACL on the Cisco router. > > > > > > > - roy - > > > > > ------------------------------------------------------------------------- > > >| roy alcala | MCI | > > >| IP Development | 2100 Reston Parkway | > > >| roy(a)mci.net | Reston, Virginia 22091 | > > >| beep-roy(a)mci.net (pager) | (703) 715-7425 | > > >| (800) SKY-PAGE PIN 1633689 | (703) 715-7066 FAX | > > > ------------------------------------------------------------------------- > > > > >> > > >> > > >>Anyone have any insights on what causes the following interesting data > > >>from a traceroute? > > >> > > >>10 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 39 ms 36 ms 38 ms > > >>11 * cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * > > >>12 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 38 ms * * > > >>13 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 41 ms * * > > >>14 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 194 ms * * > > >>15 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * * > > >>16 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * 37 ms > > >>17 * cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 37 ms * > > >>18 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 37 ms * 35 ms > > >> > > > > > -- > Peter Galbavy > @ Home in Wonderland > http://www.wonderland.org/ http://www.whirl-y-gig.org.uk/ http://www.demon.net > Be remembered not for your final destination, but for your journey. >

1 0

Re: Alpha test of MAE filtering capability
by Matthew E. Pearson 31 Jan '97

31 Jan '97

At 05:59 PM 1/30/97 -0800, Robert Bowman wrote: >But any reasonable ISP realizes that by using the RADB servers is wonderful, >but does not come close to preventing an: >ip route 0.0.0.0 0.0.0.0 <innocent ISP> > >But I presume this solution does. This is true... If indeed that is what this solution handles.. ------------------------------------------------- Matthew E. Pearson Vice President of Development Games-Online Inc. http://www.games-online.com

1 0

Re: Alpha test of MAE filtering capability
by Sean Donelan 31 Jan '97

31 Jan '97

>But any reasonable ISP realizes that by using the RADB servers is wonderful, >but does not come close to preventing an: >ip route 0.0.0.0 0.0.0.0 <innocent ISP> Nor can the route servers tell when someone/something blocks packets down at the layer 2 level. Since the route servers are now being paid by the exchange point operators, maybe there is a chance the two could be coordinated. Or at least checked for conflicts? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Alpha test of MAE filtering capability
by Matthew E. Pearson 31 Jan '97

31 Jan '97

At 03:51 PM 1/30/97 -0800, Steve Feldman wrote: >In response to requests from several customers for a filtering solution >at MAE EAST and MAE WEST, MFS WorldCom is developing an automated >system to enable ISPs to control traffic destined for their own routers >and networks. > >ISPs using this service will be able to specify, by IP address, which >MAE-attached routers they wish to accept or block traffic from. > Or you could just your the RADB Route Servers like a reasonable ISP :) ------------------------------------------------- Matthew E. Pearson Vice President of Development Games-Online Inc. http://www.games-online.com

2 1

NOTES now have a search engine
by sob＠academ.com 31 Jan '97

31 Jan '97

I have added a search engine on the NANOG notes. You can get there at this URL: http://www.academ.com/Architext/AT-NANOG_NOTESquery.html

1 0

What will they think of next?
by Steven Eric Rubin 30 Jan '97

30 Jan '97

I pulled this off of ba.internet, thought you might find this interesting.. Name of poster removed to changed to protect the less enlightend --- Hi folks, Many of you already know me. I've been around in ba.internet and ba.news for a long time, and I'm not one to spam. I've been looking at the problem of congestion for quite a while now, trying to come up with a reasonable plan - and I think I have. For the long answer, see [sorry, Im protecting the guy]. For the short answer - how about a place where the small ISP can come, locate a router, and peer with a bunch of other ISPs? You don't need PI space, you don't need BGP4, and you don't have a $3000 per month co-lo bill. We will peer using OSPF, which almost all routers support. This will keep the local traffic local, and allow the small ISP to actually get a reasonable price for bandwidth to other local sites.

2 1

RE: peering charges?
by Vadim Antonov 30 Jan '97

30 Jan '97

Eric D. Madison <madison(a)acsi.net> wrote: >Well, that's not exactly true, UUNet nor PSI show "profits", they show >substantial Revenue. Well, that's not exactly true. Comm Week, Jan 20 1997, "Content Will Ultimately Win the Game for ISPs" By Wayne Rash": I mentioned PSINet and Uunet last week, explaining that both companies were dumping their retail consumers and concentrating on business customers. As a result of this change in strategy, both companies are announcing profits for the last quarter of 1996, which is nearly unheard of in the Internet industry. >Revenue will cause Wall Street to favor your stock >even if you don't show real profits. When money are going to upgrades you can always get profit by slowing down sales. Like, by increasing prices or by dumping less profitable customers. That causes loss of market share, unless competitors are doing the slow-down act as well. Which they do (except maybe MCI). It's kind of pocker game with no limit... >The only company in the Internet >business that shows real profit is Cisco, and they are laughing all the way >to the bank. Of course vendors always have higher profit margin than >service companies. Well, most of Cisco's profit is coming from small boxes. _The_ laughing company is Intel... --vadim

1 0

RE: peering charges?
by Eric D. Madison 30 Jan '97

30 Jan '97

Well, that's not exactly true, UUNet nor PSI show "profits", they show substantial Revenue. Revenue will cause Wall Street to favor your stock even if you don't show real profits. The only company in the Internet business that shows real profit is Cisco, and they are laughing all the way to the bank. Of course vendors always have higher profit margin than service companies. Here is a financial statement for PSI: Their revenue is up tremendously but their bucket has a big hole in the bottom as does most other providers. Capital expenditure in this business is just so high. PSINet Inc. Corporate Performance 1995 1994 1993 1992 1991 ...................................................................... Revenues ($Mil) 38.7 15.2 8.7 6.4 4.7 Net Profit ($Mil) -53.2 -5.3 -1.9 0.4 0.2 EPS -1.78 -0.26 n/m n/m n/m Net Profit Margin (%) -137.3 -35.1 -22.1 6.7 5.0 UUNet info wasn't available because of the Merger.. their ticker doesn't show up anymore. I know they did not show profits because just before their merger I looked at all of the big players stock to see if there was anymone actually making money, and none has positive profits or margins. At 02:56 AM 1/29/97 -0800, you wrote: >>From Danny Stroud <dannystroud(a)msn.com>: > >>Don't harangue me about it. Ask Wall Street, look at the numbers for the ISPs, >>read the paper regarding the latest AOL flap. This is not my sole opinion. I >>will not engage in a philosophical debate on this issue. Sorry, but the >>market is the judge. des > >He. UUNET and PSI show profits even after lots of money spent >on expansion. Zillions of small ISPs which "resell" UUNET's and PSI's >services are profitable (or they'd close the shop long time ago, because >they generally have no cash reserves, and no VC funding). Sprint >and MCI do not show profits on Internet side, but their leased line >business is _very_ healthy because Internet sells those lines. > >If anything, telcos provide equivalemt of 64Kbps digital service to anyone >for the same $20/mo and are not particularly bankrupt. > >One has to be completely insane to call the industry with nearly decade of more >than 100% annual growth "not economically viable". One has to read way too much >creative economists (of statist camp) to believe in anything like that. For once, >those economists missed the entire new industry. Now they pretend it doesn't >exist or offer moronic suggestions on how to "fix" it. How nice, but we've >already seen exactly that scenario with PCs. > >--vadim > >PS AOL "flap" is a typical example of blatant incompetence. > Their marketroids never heard of market pilots, or something, > to measure response before doing something really drastic. > > If AOL will go under as a result, they won't get a lot of sympathy. > >PPS What figures? I've certainly seen a lot of creative accounting, > when, for example, network build-up is counted as operational > expense (Sprint used to do that), whereas all sane people count it > as capital. > >PPPS Wall Street who? I guess not the people who valued UUNET at $2B, > right? > 4 >P S May i politely suggest reading some books on the early history of > telephony before writing nonsense? Fortunately, they had fewer > economists and lawyers back then (though, Bell had to defend his > patents against 576 suits). > >

1 0

Domain names for ISP infrastructure links
by Peter Lothberg 30 Jan '97

30 Jan '97

So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC? --Peter

15 18