September 1998 - Test - lists.nanog.org

RE: Is anyone else seeing this?
by Martin, Christian 15 Sep '98

15 Sep '98

I'm seeing these as /17s... PHIL-RTR1#sh ip bgp 146.188.136.0 BGP routing table entry for 146.188.128.0/17, version 173845 Paths: (3 available, best #2, advertised over IBGP, EBGP) 3951 701 Chris -----Original Message----- From: alex(a)tempest.nac.net [mailto:alex@tempest.nac.net] Sent: Tuesday, September 15, 1998 1:14 AM To: nanog(a)merit.edu Subject: Is anyone else seeing this? Thousands of /30's from UU? *>i146.188.136.12/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.16/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.24/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.28/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.32/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.36/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.40/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.44/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.48/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.52/30 207.99.5.196 100 0 7372 701 i *>i146.188.136.56/30 207.99.5.196 100 0 7372 701 i -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

1 0

Re: Flash crowds and network management
by Sean Donelan 14 Sep '98

14 Sep '98

>Using fast-cgi and such helps a bunch. Of course, for all I know, they >did that already. I don't think anyone (media or government) was using cgi for the first hour or so. Pretty much everything besides the plain text html was stripped off the pages. I noticed some of the media sites even stripped off the advertising banners, and doubleclick.com was warning its subscribers about the load. Obviously the government sites didn't have any ad banners. Although it does bring up an interesting point. Do things like doubleclick.com become unforeseen cascade points in the net? They create link between normally unrelated sites which may also link the traffic management problems. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

/dev/null procmail rules
by Forrest W. Christian 14 Sep '98

14 Sep '98

I've finally had enough... Would someone be kind enough to send me their procmail recipie which forwards mail from a certain unnamed person who has the initials J.F. to the appropriate file (/dev/null)? In interest of keeping the noise level down in nanog, I'm willing to forward any recipies I recieve to anyone who asks me for them. In other words, please don't respond to the mailing list. There's enough noise in there already. Thanks. - Forrest W. Christian (forrestc(a)imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

2 1

Re: The Cidr Report
by Brian Dickson 14 Sep '98

14 Sep '98

>Anyone care to comment on the fact that the top non-compliant companies >never really seem to make any significant changes? > >> --- 11Sep98 --- >> ASnum NetsNow NetsCIDR NetGain % Gain Description >> AS174 789 611 178 22.6% Performance Systems International >> AS2493 373 217 156 41.8% iSTAR Internet, Inc. Well, two things: (1) PSI acquired iSTAR; (2) most of the clueful people had left or have left iSTAR (myself being one). I have no specific knowledge of PSI's clue quotient, per se. Also of note: all of iSTAR's unaggregated routes are below 206.0.0.0/8, in geographically-assigned /16's (ie, some /24's belong to iSTAR customers, some to customers of other providers), where the %gain is achieved by aggregating in variable-length clumps (eg /23's, /22's, etc), at iSTAR's EBGP borders, since these are not aggregatable internally. And yes, iSTAR does redistribute its IGP into BGP, but only because Cisco's IOS has a limit (200) on how many "network" statements can exist in a router, which is exceeded by their NetsCIDR. :-( -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

1 0

Friday's Outage
by Tim Wolfe 14 Sep '98

14 Sep '98

Sean et al. Any further info on the results of Friday's train derailment as it relates to the Net slowdown/release of the Starr report? Also, how long were things down before Worldcom/MFS were able to get things spliced back together? Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

MAE ATM and distant connections
by Aleksi Suhonen 14 Sep '98

14 Sep '98

Hello, I'd like your opinion on the following concept. It is non-specific to any single MAE or continent but my original idea is of MAE-EAST and Europe. An overseas operator could get a circuit from one of its POPs directly to the MAE ATM switch (matrix) and set up peering PVCs between its peers and the router(s) in its POP overseas. This would eliminate the need for colo space and remote hands service for an overseas router from the operator's point of view. I can immediately think of four drawbacks to this: 1) Routing Protocol Latency This shouldn't be an issue with BGP. 2) Routing Protocol Bandwidth Waste This would only be an issue if the operator would receive lots of same routes from two or more peers. To be a constant issue those routes would need to flap a lot too. 3) Router Not On Shared Medium (Ethernet, FDDI) This could be overcome by some cooperation with a local provider that has a switch between its shared medium connection and its router. The switch should be capable of ATM LANE though and MAE ATM switches would need more complex configuration as well. Ideally the MAE ATM switches would do it directly, but I'm not sure thay are capable of it? 4) Bandwidth Waste From ATM Encapsulation A POS circuit would use the long distance bandwidth more efficiently. -- Aleksi Suhonen Network Development Saunalahden Serveri Oy AXU-RIPE Please keep me in the Cc:-field as I'm not subscribed to the list.

2 1

Re: Flash crowds and network management
by Leo Bicknell 14 Sep '98

14 Sep '98

In article <6thaou$rhd(a)gizmo.dimension.net> you write: >I'd like to chat someday with the webserver managers at some of >the large media web farms someday, not necessarily with a reporter >listening in, about what they were seeing. But at the moment there >isn't a real good way for us to communicate in real-time about what >is going on. Well, it's not quite talking to them, but CNN's web site does have an interested tidbit in it. See http://cnn.com/TECH/computing/9809/11/internet.congestion/index.html for the whole story, here's the interesting paragraph: At CNN's Web site, CNN Interactive, the number of hits peaked at an estimated 340,000 per minute, eclipsing all previous traffic volumes. To ease the crush, CNN.com stripped out pictures and graphics to present a text-only version. That's 5600 hits a second, for those who don't want to fire up bc. Not bad. -- Leo Bicknell - bicknell(a)dimension.net Network Engineer (CCIE #3440) - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

4 3

Re: Using NAT for best-exit routing
by Paul Vixie 14 Sep '98

14 Sep '98

> I work for a Finnish ISP and from my perspective all you American > providers are "one huge Exodus." We battle with the issue by providing > customers with an efficient web cache system. So basically what I'm > saying is that GTEI could go a long way in solving the problem of > asymmetric peering traffic due to web farm providers with an efficient > web cache system for their customers. > > On my continent this is almost an unwritten responsibility of an ISP. I don't know where it will end, but at the moment 55% of the web traffic I see from my transparent cache customer log files is dynamic. That means 55% of the bytes flowing through port 80 at various chokepoints is marked uncacheable by the origins. My product finesses this up to and a little bit beyond what the HTTP spec allows, trying to distinguish between stuff that's marked uncacheable for advertising hit-rate reasons but is in fact quite static, compared to stuff that really is dynamically (usually CGI) generated and really isn't cacheable. Inktomi breaks even more rules than we do but their hit rate is still pretty marginal. The web pretty much just does not cache well, primarily because the people who generate content aren't the ones who get hurt by its uncacheability. During the time between October 1996 and now (September 1998), I've watched the percentage-uncacheable mark rise from 20% to 55%. It could stabilize at 55%. I don't think it will go down though. More likely it will rise a little further, since there are so many web site construction kits on the market that don't care one whit for cacheability (or the HTTP standard, but that's another story.) If you're still thinking of web objects as files, go spend some time with some marketing people and learn about "web-enabled applications" which is not about files at all. (You'd also learn the reason why I'm not expecting to sell very many more of my transparent web caches.) So, I'm all for having ISP's run caches and either offer transparent interception or some other automatic browser/cache relationship builder. But until we get a reasonable mechanism for _generating_ the content in multiple places we're going to have to provision the paths and servers and peering points with the brute force needed to move data from single sources to an outrageous and growing number of destinations. I'd say (returning to the topic of the message I'm replying to) that GTE/I and other carriers will have to argue about peering and assymetry for another six months at least before the right content distributions start to emerge. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

2 1

NY times appears to have had a rough morning..
by Richard Irving 14 Sep '98

14 Sep '98

Hrmm.. This sunday am I logged into www.nytimes.com, and got an unusual front page. Someone may want to take a look...... Richard :(

5 4

nytimes?
by Andy Walden 14 Sep '98

14 Sep '98

I can't get to it, what did you see? Sincerely, Andy Walden System Administrator MTCO Communications 1-800-859-6826

2 1