- Test - lists.nanog.org

Re: sell shell accounts?
by salo＠msc.edu 23 Jul '96

23 Jul '96

> Subject: Re: sell shell accounts? > To: freedman(a)netaxs.com (Avi Freedman) > Date: Fri, 19 Jul 1996 16:34:27 -0500 (CDT) > From: "Karl Denninger, MCSNet" <karl(a)mcs.com> > Cc: vansax(a)atmnet.net, richards(a)netrex.com, agislist(a)interstice.com, > nanog(a)merit.edu > [...] > > The question is: Will there be routers available that can make IP > > routing decisions based on 40-60kroutes and move 2-3 OC3s worth of > > bidirectional traffic? ... > > Avi > > Uh, yes. Like today. > > See NetStar (recently acquired by ASCEND). > > Their hardware does nothing *slower* than DS-3 right now, and updates the > route forwarding table 20x/second. :-) > > This thing is a monster, and will make the so-called "state of the art" > 7513s look like dogmeat when in full production (presuming the BGP issues > get completely resolved). I think there are a number of measures, beyond the speed of the interfaces, which are important when thinking about fast boxes: o Aggregate bandwidth of the box in bps. o Aggregate bandwidth of the box in packets per second. o Amount of buffering in box; (can TCP gracefully back off?) o And, a whole pile of specific, often implementation- dependent measures, regularly discussed on this list. Some boxes do very well on some of these measures, but not too well on others. An extreme example is a HIPPI switch: really fast interfaces (800 or even 1600 Mbps), lots of aggregate bandwidth (gigabits/sec), but almost no buffering and not good for more than a few hundred or a few thousand packets per second, (although the attached hosts often are responsible for much of this limitation). Also, things go much better if the HIPPI hosts are in the same room. Nonetheless, they are really fast based on select measurements... -tjs By the way, I like the NetStar box and wish them well.

1 0

Hotel Info for October NANOG Meeting
by Pam Ciesla 23 Jul '96

23 Jul '96

Hotel info is available on the Merit Web Page for the October NANOG Meeting http://www.merit.edu/. Please mention the NANOG Meeting when making your reservations at the hotels with blocked rooms. The Holiday Inn room block is until 10/9/96 all others end 9/23/96. Although this is not a football weekend, hotel rooms are at a premium, so book early. Shuttles will be provided from the hotel to the meeing from the Holiday Inn & the Sheraton Inn, the Bell Tower & Campus Inn are within walking distance and the Weber Inn you are on your own. If you have any problems making reservations please contact me. Thanks Pam Ciesla

1 0

NetSCARF Release 1.1 Available
by William B. Norton 23 Jul '96

23 Jul '96

N E T S C A R F R E L E A S E 1.1 Hi all - In April, Merit received funding from the Resource Allocation Committee (RAC) to develop and evolve a prototype ISP Network Statistics Collection And Reporting Facility (NetSCARF) package. The basic idea is to make it dead easy for ISPs to collect and report data about their part of the Internet. We expect about three more releases during the next 8 months, based on the feedback we get from the ISP and R&E community. The end result will hopefully be widely-available and consistent ISP performance data much as Merit produced during the operation of the NSFNET. The 1st public release of the software is now available at: http://www.merit.edu/~netscarf A technical overview article is being published in the July Connexions magazine (Vol. 10 No. 6) and some on-line docs exist at the above URL as well. The NetSCARF Code -------------------------- The NetSCARF code is easy to install, runs automatically, and consists of four separate programs. Every fifteen minutes the collections program queries all network nodes in parallel. (This is especially important for large networks where the serial skew can affect the ability to correlate data.) Nightly these raw statistics get pre-processed (cooked). The cooked data is delivered to CGI scripts using what we think is the first Public Domain implementation of the OpStats (rfc1856) client/server model. Finally, ISP performance reports (based on the cooked data) are displayed on the web via the CGI scripts. The source and pre-compiled executables are available for each of these on the BSDi and SunOS platforms. SNMP Version 1 is used to query the network nodes, although the code includes support for the User Security (USEC) model for SNMPv2. ( The Routing Arbiter project will use the privacy (DES Encryption) facility, but this capability is disabled for the public release due to export restrictions. You do get the benefits of authenticated management communications with the released SNMPv2u code though.) Release 2 is scheduled for October and will include ports to Windows NT, AIX, and perhaps Solaris and LINUX. We are primarily customer-driven in choosing additional features, but our own experience so far leads us to adding a few features to release 2 including raw network statistics maintenance functions, raw data file compression, and another report or two. During the operation of the NSFNET we found there were really only three graphs that were widely seen as useful. The first cut of the code includes only these three most popular graphs: System UpTime, Interface Uptime, and the McD's chart (total packets served) by the network. There is a mailing list (netscarf(a)merit.edu) for community discussion and guidance. Details are available at the URL above. Cheers - Bill ---------------------------------------------------------------------- William Norton <wbn(a)merit.edu> (313) 936-2656

1 0

Re: Why aren't ISPs providing stratum 1 NTP service?
by dgaudet＠hotwired.com 23 Jul '96

23 Jul '96

In article <hot.mailing-lists.nanog-199607222012.AA05135(a)jotun.EU.net>, Per Gregers Bilse <bilse(a)EU.net> wrote: >Yep, works. Management isn't a problem if each box is fitted with >two interfaces and addresses, one for public consumption of contents, >one for internal use. Not that we have done any of this for real (yet). I've actually been doing that here for months (different service and mgmt addresses). If you dig www.hotwired.com both those addresses exist on two machines, and are on loopbacks. There's a bunch of nice tricks you can pull. But I feel like I'm going to get flamed for straying away from network operations. Oops. Dean

1 0

Canadian routes with BGP no-export communities
by Sean Donelan 22 Jul '96

22 Jul '96

Does anyone know what's going on in Canada? In the last couple of weeks fONOROLA/iStar.net changed how they announce aggregated networks. Now fONOROLA is sending some more specific network announcements for multi-homed networks in 198.53.0.0 with a "no-export" BGP community to MCI, and ANS. As long as you only connect with MCI or ANS, and use their IGP, things look pretty typical because the more specifics are carried internally. But if you use BGP, the no-export means any peers with MCI won't see the more specific network announcement from MCI. The problem shows up when you see routes from Sprintlink. A few Canadian network connect through Sprint/Canada as well as fONOROLA. The more specific networks from 198.53 are announced by Sprintlink. Since the no-export suppressed the more specific announcement to MCI BGP peers, the traffic for those Canadian sites follows the more specific network announcement and heads for Sprint. I understand the BGP mechanics are working as specified, so it isn't "broken" per se. But I'm just wondering if Canadian sites really expect traffic to go via Stockton, California? I haven't been able to reach anyone at fONOROLA/Istar. I was just wondering if any other North American network operators had heard what was supposed to happen last month when fONOROLA made these changes. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

NANOG spamming?
by Hank Nussbacher 22 Jul '96

22 Jul '96

Have other received this spam from an outfit located at MAE-Dallas? Is this a harbinger of spams to come? -Hank ---------------------------------------------------------------------- To: hank(a)ibm.net.il From: Internet Resources Group <F00103200027894(a)[206.245.228.50]> Subject: Remote Web Site Monitoring Service Date: Wed, 17 Jul 1996 17:35:45 -0500 Greetings Webmaster! Internet Resources Group announces Red Alert Web Site Monitoring Service. Red Alert is an independent, off-site service that checks your essential URLs 4 times/hour, 24 x 7, and immediately pages or emails you if your site becomes inaccessible or returns incorrect data. Located in the MAE-Dallas building, Red Alert notifies you with intelligent alerts in cases of server crash, ISP outage or CGI failure. And Red Alert keeps you in control with a real-time, Web based user interface. Red Alert monitors Chase Manhattan Bank, First USA, VISA, PepsiCo, large ISPs including Internet America and MCI, entrepreneurs such as AudioNet, and small businesses worldwide. Try it risk-free for 30 days. No credit card required. Immediate activation. http://www.redalert.com/red07/ We look forward to serving you. Michael Martin, CEO 1.214.422.6364 1.214.422.6366 fax Internet Resources Group -- 821 Ashburn Place -- Plano TX 75075 USA PS--If this message is a duplicate, you may be on our announcement list under two different addresses. If so, please reply with "remove" in the subject. ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il WWW: http://www.ibm.net.il/~hank ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

4 3

Re: sell shell accounts?
by Avi Freedman 22 Jul '96

22 Jul '96

> If you have full use of the fiber across which you move your packets you > can create a mesh of PVCs directly connecting each router thus decreasing > the hop count. The same can be done when using an existing cell-relay cloud, > but you pay on a per pvc basis so the benefit needs to be weighed against the > cost. Of course the packets still flow along the same physical path and in a > wide area network the time in transit will be more significant than the time > to get through the routers. > > Jim Nope, remember - there is no magic. Any mesh of PVCs that one makes over a switched network must reflect the toplogy of that network, and one can set up a matching set of active routing sessions and route weights which will cause traffic to flow the same way. Yes, the switches are a bit faster and have less to do. Data moves through them in a few ms less per point. But as you said (and as I said in our discussion in NYC), relative to any distance, the speed of light guarantees that you won't notice the difference. The question is: Will there be routers available that can make IP routing decisions based on 40-60kroutes and move 2-3 OC3s worth of bidirectional traffic? The building of the configs to have a routed network work the same as a switched ATM one can be automated, but it's true that it *can be* easier to see what's going on in a large-scale switched network. Avi

9 21

Re: T3 or not to T3
by sob＠academ.com 22 Jul '96

22 Jul '96

> From stuff I've seen here and elsewhere I think the most important reason > for this is congestion at NAPs making it impossible to suck (or shove) > lots of bandwidth at anything but your provider's backbone. In using "NAPs" above, are you just talking about the NSF NAPs or all interconnections? I think it may be an overstatement to say that all NAPs are congested. Perhaps that not what you meant. My experience is that provider backbones are congested at times as well. It is unclear how fast providers can address these types of problems. My experience is that providers often don't have large enough ingress into the NAPs. So, sometimes the NAPs are congested and sometimes the providers have inadequate facilities to make the best use of the NAPs. > I haven't considered yet the maintenance/logistical cost of managing > 15 T1s to 6 or 7 providers vs. the "ease" of two frac-T3s to two providers. Generally for each connection to each provider, you would have to set up BGP. This will have some cost in processing and memory in your border routers. This will also involve dealing with full routing information and maintaining valid filters relating to the the changes that occur in other parts of the Internet. I believe that some providers have people who spend full time just doing this task, so you might have to allocate the same resources to do that. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

5 5

[fwd] CIX announces relocation
by Paul Ferguson 22 Jul '96

22 Jul '96

I may have missed discussion on this earlier, but I see that CIX has decided to relocate to the Digital exchange. - paul [excerpt: 07-19-96 at 08:48 EDT, Business Wire] > >HERNDON, Va.--(BUSINESS WIRE) via Individual Inc. -- The Commercial >Internet Exchange (CIX), a non-profit trade association representing >160 Public Data Internet Service Providers, announced today it is >relocating its router from Santa Clara, California, to a Digital >Equipment Corporation (Digital) facility in Palo Alto, California. >Relocating the router, which provides many of CIX members with an IP >interconnection, is designed to provide the membership with reduced >operating costs and a higher quality of service at a co-location >facility with "hands-on" technical support. > >CIX's router and related facilities have been replicated at the Digital >facility, called the Digital Internet Exchange. Testing is currently >underway, with the cutover scheduled for July 18, 1996. The interconnection >will continue to be called the CIX NAP. The CIX router, currently located >at the Wiltel facility, will be maintained as members are transitioned to >the new facility. > [snip]

1 0

Re: T3 or not to T3
by Sean Doran 21 Jul '96

21 Jul '96

Dorian Kim writes: | Agreed. IMO, the best place for these things is one hops away from an XP, | either in a provider's network or behind a content provider's router that's | connected to the XP. Wrongthink. For righthink, please see ftp://ftp.ee.lbl.gov/talks/vj-webflame.ps.Z Pay _particular_ attention to pages 9 and 11. Please also see the excellent work by the NLANR and Squid folks, which while not quite perfectly rightthink, is a much better set of things to spend brainpower on than worrying about multiple T1s and T3s and the like. http://www.nlanr.net/Cache/ Run with these ideas. Otherwise, you will be in this rathole answering the same questions Dean Gaudet has asked, only for tens, then hundreds and then thousands of people. I suspect that we are already, as a group of smartish people, answering these questions multiple times. Meanwhile, the people thinking of producing content for mass-availability should pay attention to page 13 (the last page) of the same set of viewgraphs. Well, unless you like the fact that the popularity of your content makes it expensive for you to make it available, either due to big bills or spending many hours pondering ugly solutions to precisely the sort of problem being discussed in this thread. There will be a quiz. Sean.

1 0