- Test - lists.nanog.org

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by salo＠msc.edu 23 Jul '96

23 Jul '96

> Date: Tue, 23 Jul 1996 14:28:27 -0400 > From: Paul Ferguson <pferguso(a)cisco.com> > Subject: Re: ATM Wide-Area Networks (was: sell shell accounts?) > [...] > It depends on what you mean when you say 'performance'. I think > there is more and more interest being vested in ATM inefficiency, > and alternate technologies to better efficiency in the long-haul. > > Recall Jerry Scharf's numbers; they're indicative of the issue. > [...] > HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 > ATM framing bytes = 3644304857 ATM efficiency = 82.61 > ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95 At a certain point, some of these arguments about ATM efficiency sound a bit like saying FDDI is terrible because 4B/5B encoding is only 80% efficient. I think a more interesting measure of the value of ATM versus other wide-area technologies is some sort of measure of throughput per dollar. -tjs

1 0

CIX or CRL problems?
by sob＠academ.com 23 Jul '96

23 Jul '96

I am not able to get past 149.20.0.0 to get to CRL. Is this a problem with CRL or CIX? Does anyone know? owlman.academ.com% traceroute 140.145.0.1 traceroute to 140.145.0.1 (140.145.0.1): 1-30 hops, 38 byte packets 1 ACADEM-ISDN.ACADEM.COM (198.137.249.254) 1.99 ms (ttl=64!) 2.5 ms (ttl=64!) 1.93 ms (ttl=64!) 2 HOU6-E0.SESQUI.NET (128.241.151.86) 68.6 ms (ttl=63!) 24.1 ms (ttl=63!) 23.6 ms (ttl=63!) 3 128.241.151.83 (128.241.151.83) 295 ms 24.6 ms 37.4 ms 4 HOU1-F20.SESQUI.NET (128.241.200.81) 91.4 ms 34.2 ms 43.8 ms 5 MCI-F0.SESQUI.NET (192.67.13.189) 96.8 ms 25.7 ms 36.7 ms 6 border1-hssi1-0.Houston.mci.net (204.70.36.5) 29.5 ms 260 ms 312 ms 7 core1-fddi-0.Houston.mci.net (204.70.2.97) 421 ms 492 ms 146 ms 8 core1-hssi-4.Dallas.mci.net (204.70.1.121) 59.1 ms 108 ms 41.1 ms 9 core3.SanFrancisco.mci.net (204.70.4.17) 75.9 ms 195 ms 75.3 ms 10 mae-west-nap.SanFrancisco.mci.net (204.70.1.14) 98.9 ms 79.5 ms 103 ms 11 T3-CRL-SFO-01-H1/0.US.CRL.NET (198.32.136.10) 87.9 ms 172 ms 185 ms 12 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 122 ms (ttl=245!) 178 ms (ttl=245!) 215 ms (ttl=245!) 13 * * * 14 * * * 15 * * * .... 30 * * * owlman.academ.com% traceroute 165.113.19.6 traceroute to 165.113.19.6 (165.113.19.6): 1-30 hops, 38 byte packets 1 ACADEM-ISDN.ACADEM.COM (198.137.249.254) 74.6 ms (ttl=64!) 29.1 ms (ttl=64!) 3.8 ms (ttl=64!) 2 HOU6-E0.SESQUI.NET (128.241.151.86) 314 ms (ttl=63!) 93.7 ms (ttl=63!) 216 ms (ttl=63!) 3 128.241.151.83 (128.241.151.83) 130 ms 120 ms 96.2 ms 4 HOU1-F20.SESQUI.NET (128.241.200.81) 202 ms 282 ms 889 ms 5 MCI-F0.SESQUI.NET (192.67.13.189) 206 ms 25.8 ms 25.0 ms 6 border1-hssi1-0.Houston.mci.net (204.70.36.5) 29.5 ms 35.4 ms 36.8 ms 7 core1-fddi-0.Houston.mci.net (204.70.2.97) 81.9 ms 160 ms 233 ms 8 core1-hssi-4.Dallas.mci.net (204.70.1.121) 35.9 ms 193 ms 165 ms 9 core3.SanFrancisco.mci.net (204.70.4.17) 233 ms * 128 ms 10 mae-west-nap.SanFrancisco.mci.net (204.70.1.14) 135 ms 271 ms 311 ms 11 T3-CRL-SFO-01-H1/0.US.CRL.NET (198.32.136.10) 178 ms 114 ms 80.3 ms 12 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 98.2 ms (ttl=245!) 137 ms (ttl=245!) 255 ms (ttl=245!) 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 116 ms (ttl=245!) !H * *

3 3

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by Paul Ferguson 23 Jul '96

23 Jul '96

At 10:22 AM 7/23/96 -0700, Dave Siegel wrote: > >It's difficult to quantify wrt to how ATM plays a role in end-to-end >performance on the Internet. There is very little research to support how >ATM affects the overall performance. Even Ameritech and PacBell restricted >the majority of their performance evaluation on performance in the switch, >and only extended their scope if they leased an ADSU to a customer. Even >with the improved buffering, if you fill your pipe into the ATM switch, >your ATM switch still becomes a packet shredder, compared to the more >graceful packet drops seen on a clear channel line. > It depends on what you mean when you say 'performance'. I think there is more and more interest being vested in ATM inefficiency, and alternate technologies to better efficiency in the long-haul. Recall Jerry Scharf's numbers; they're indicative of the issue. [snip] Date: Tue, 18 Jun 1996 23:24:12 -0700 (PDT) From: scharf(a)vix.com (Jerry Scharf) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: nanog(a)merit.edu Subject: tilting at windmills discussion 2 Sender: owner-nanog(a)merit.edu In an attempt to reduce the signal to noise ratio of NANOG, I felt like ATM should get equal time with registry policy for unending discussion of week award. In Bob Melcalfe's concept that all we care about is working code, I have included a PERL program for your benefit. The programs reads a histogram file like the ones kc generates from mae-west (http://www.nlanr.net/NA/Learn/packetsizes.html) and computes the overhead for various framing methods. Hopefully taking empirical data from the internet and giving people code will reduce the discussions of what the "cell tax" for real traffic is. Don't like my traffic, collect your own. Fighting over conclusions will be left to others. Jerry Here's the output from the 15 minute collection run on Feb 10th, '96: % packettax.pl < packetsizes.data total packets seen = 11708789, total payload bytes seen = 3010380871 HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 ATM framing bytes = 3644304857 ATM efficiency = 82.61 ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95 [snip] - paul

1 0

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