- Test - lists.nanog.org

Re: Creating exchanges
by Thomas P. Koltai 21 Oct '96

21 Oct '96

On Fri, 11 Oct 1996 15:11:29 -0700 (PDT) bmanning(a)ISI.EDU wrote: >> <SNIP> > >Oh... btw, the "wnog" would really be the IEPG. iepg(a)iepg.org >Or, since this has a distinctly PacRim flavor, APOPS. > Nope, can't be IEPG. gih@telstra has already snaffued that one. In April 1994!!!! Geoff, I thought I was a visionary... chuckle. Tom ------------------------- Thomas P. Koltai Phone: +61-2-261-4884 Mobile: +61-414-574-242 185 Liverpool Street, Sydney NSW 2000 -------------------------

1 0

Re: Ungodly packet loss rates
by Edward Vielmetti 21 Oct '96

21 Oct '96

my suggestion would be to ask cisco what isp they recommend for dialup access from your location, and dial in through them. you should be able to lop off 60% of your hops and probably 99% of your problems if you pick right. You're transiting two NAPs (MAE-WEST and the DEC exchange (?)) which both provide service that's essential on one hand (wide access to the greater Internet) and lousy on the other hand (focussed access to a particular site). If you want good internet service to a particular point on the network, you must shop for it specifically and be prepared to continue to shop for it whenever the underlying network topology changes. Ed Edward Vielmetti emv(a)coast.net

2 1

NANOG Meeting Info
by Pam Ciesla 21 Oct '96

21 Oct '96

Shuttles from hotels to meeting: Holiday Inn Thursday 10/24 Depart 8:00AM Pickup at MI Union 5:15PM Friday 10/25 Depart 8:00AM Pickup at MI Union 1:15PM Sheraton Thursday 10/24 Depart 8:00AM Pickup at MI Union 5:30PM Friday 10/25 Depart 8:00AM Pickup at MI Union 1:10PM NOTE: SIGN UP SHEET AVAILABLE AT HOTEL WHEN YOU CHECK IN Pam

1 0

Ungodly packet loss rates
by jbash＠velvet.com 21 Oct '96

21 Oct '96

[Resent... I stupidly used the wrong address for the NANOG list] This is being sent to the "help-line" addresses of several Internet providers because they're not providing what I consider appropriate service. It's being sent to the NANOG mailing list because it represents what I believe to be an industry-wide problem. I'm just a lowly end user, and perhaps I shouldn't intrude into the councils of the Wise and the Great, but this is just a bit ridiculous. Attached is a traceroute from my home machine to the system I'm trying to work on over a TELNET session. It looks like there's about a 40-percent overall round-trip loss rate, most or all of it apparently introduced in the Alternet and BBN Planet backbones. This is not a transient condition; it's been going on for at least several days, and similar things happen all the time. I think we can all agree that a 40-percent loss rate isn't an acceptable level of service in an IP network. It's certainly making it annoying and frustrating for me to try to work. It's also driving up the load on the network by provoking retransmissions. A corporate internal network running at that loss rate would probably be considered to be in collapse. I pay TLGnet (now Best) an agreed-upon amount of money every month, nominally in exchange for a reasonable level of Internet service. I think that part of TLGnet's obligation under that arrangement is to contract for reliable backbone service. Likewise, the other end of the path (Cisco systems, for whom I am emphatically not, *not, *NOT* speaking here) pays BBN what I suspect to be a very large amount of money indeed for DS3 service, presumably in the expectation that most of the packets that go into the DS3 will come out of the network somewhere. Alternet presumably has agreements with both TLGnet and BBN. That puts everybody on the hook. I fully understand that it's difficult to provide reliable service in an exponentially-growing network. I'm aware that everybody's already using the fastest lines they can get, and connecting the fastest routers to them. I know that links are being added. I appreciate that both lines and equipment are very expensive, and that adding lines serves to complicate an already amazingly complex router configuration situation. I understand that cash-flow issues (as well as convincing-the-bean-counters issues) are involved. I sympathize... ... but the fact remains that I'm not getting the level of service I think I'm entitled to, nor are other end users. Not only that, but if the level of service gets any lower, the Net will become so painful to use that I'll start wondering why I bother. While reducing my Net use might be good for my mental health, I don't think anybody wants to see users abandoning the Net because of poor service. So, what's to be done about it? Assuming that all technical means are being pursued, and from what I've seen on various mailing lists I believe they probably are, the only thing left is a management fix. May I make the probably-sacreligous suggestion that the industry as a whole, and the providers I've mentioned in particular, show greater concern for the quality of service provided, and specifically-- 1. Stop taking on new customers (or other traffic sources) until existing customers can be provided with an appropriate level of service. 2. Develop meaningful quality-of-service standards that can be used to guarantee reasonable performance in terms of end-to-end drop rates, delays, and downtime. 3. Reexamine both pricing levels and the Internet pricing model, to make sure that there's enough money available to fund a usable level of service. Yes, this means giving up some business. That's one of the costs of honoring your agreements... and of not alienating an entire generation of customers. Thank you for your attention. Although I usually scan at least the subject lines of messages sent to the NANOG list, I'm temporarily without access to the news server on which I ordinarily read the list. For the next few days, I won't be able to answer replies not sent to me directly. -- J. Bashinski blue% traceroute -a -q 25 -Q champagne.cisco.com traceroute to checkpoint-sj.cisco.com (171.69.10.37), 30 hops max, 40 byte packets 1 tongue.velvet.com (206.14.77.65) (2.8 ms/3.6 ms(+-0.9 ms)/15.8 ms) 25/25 (100.00%) 2 tlg-cust-link.tlg.net (140.174.151.93) (39.0 ms/47.5 ms(+-10.3 ms)/134.8 ms) 25/25 (100.00%) 3 mae-west.tlg.net (198.32.136.22) (40.7 ms/45.6 ms(+-9.2 ms)/57.0 ms) 25/25 (100.00%) 4 905.Hssi3-0.GW1.SCL1.ALTER.NET (137.39.133.89) (43.9 ms/49.1 ms(+-9.9 ms)/60.8 ms) 25/25 (100.00%) 5 Fddi0-0.CR1.SCL1.Alter.Net (137.39.19.5) (43.5 ms/48.8 ms(+-9.8 ms)/57.0 ms) 25/25 (100.00%) 6 Hssi3-0.San-Jose3.CA.Alter.Net (137.39.100.1) * * (45.3 ms/52.5 ms(+-11.1 ms)/77.6 ms) 23/25 (92.00%) 7 Fddi0-0.San-Jose6.CA.Alter.Net (137.39.27.12) * (44.4 ms/49.6 ms(+-10.2 ms)/60.8 ms) 24/25 (96.00%) 8 Hssi1-0.Palo-Alto2.CA.ALTER.NET (137.39.101.162) (46.7 ms/52.6 ms(+-10.5 ms)/61.6 ms) 25/25 (100.00%) 9 Fddi1-0.Palo-Alto3.CA.Alter.Net (137.39.47.7) * * * * * (57.9 ms/82.0 ms(+-21.6 ms)/248.5 ms) 20/25 (80.00%) 10 decwrl.bbnplanet.net (198.32.176.5) * * * * * * (50.4 ms/60.8 ms(+-14.0 ms)/68.9 ms) 19/25 (76.00%) 11 paloalto-br1.bbnplanet.net (4.0.1.57) * * * * * * (52.7 ms/63.6 ms(+-14.7 ms)/82.3 ms) 19/25 (76.00%) 12 paloalto-cisco.bbnplanet.net (131.119.0.196) * * * * * * * (57.0 ms/66.2 ms(+-15.7 ms)/80.7 ms) 18/25 (72.00%) 13 * 131.119.26.10 (131.119.26.10) * * * * * (54.8 ms/65.6 ms(+-15.1 ms)/75.6 ms) 19/25 (76.00%) 14 sj-wall-2.cisco.com (192.31.7.34) * * * * * (48.2 ms/77.2 ms(+-18.4 ms)/151.9 ms) 20/25 (80.00%) 15 * * * * * sj-eng-corp2.cisco.com (198.92.1.130) * * * * * (58.5 ms/70.3 ms(+-18.2 ms)/81.2 ms) 15/25 (60.00%) 16 * eng-atm-gw2.cisco.com (171.69.4.129) * * * * * * * * * (61.9 ms/67.1 ms(+-17.4 ms)/78.7 ms) 15/25 (60.00%) 17 sj-eng-corp1.cisco.com (171.69.5.10) * * * * * * * (52.2 ms/64.9 ms(+-15.4 ms)/81.8 ms) 18/25 (72.00%) 18 checkpoint-sj.cisco.com (171.69.10.37) * * * * * * * * * * * * * * * * (58.1 ms/78.6 ms(+-30.0 ms)/202.2 ms) 9/25 (36.00%)

2 1

Re: GigaRouter (Was Re: Cisco as Big Brother))
by Rob Liebschutz 21 Oct '96

21 Oct '96

I've spent days on the phone with [substitute your favorite router vendor here] customer support and engineers tracking down bugs in their routing software and trying to get bug fixes and workarounds from them, and I've spent comparable days running gdb on gated and staring at gated code and my personal opinion is that working with the gated code was a far more valuable experience for me. Gated is very stable for me now, and if I don't like the way something works, I change it or add a new feature if I want. My experience in consulting has taught me that off the shelf products from vendors with professional customer support (i.e. black boxes approved by Fortune 500 companies) are better for some clients, but I have clients that appreciate software like gated and are willing to pay for my time to work with it. You can always join the gated consortium. The gated web pages at Merit indicate that there is some level of support available for those willing to pay for it. Can anyone with experience comment on this? Is source code and a development environment available (and afordable) for the gated implementation in the Netstar product? If it is and the product is reasonable in other ways, I'd be on their doorstep in a minute. Are source licences available from any of the other major router vendors? > alex(a)relcom.eu.net writes: > > > > > > > > >Subject: Re: GigaRouter (Was Re: Cisco as Big Brother)) > > > >From: dvv(a)sprint.net (Dima Volodin) > > > > > > >You said - "gated"? Oh my gawd... > > > > > > I agree. Oh my gawd, someone is using one of the most efficient and > > > reliable pieces of routing code around. What a really great idea. There > > > are other smart router vendors who use various route and policy storage > > > data structures from gated. Oh my gawd. Some smart router vendors are > > > implementing dynamic non-intrusive policy config on their routers this > > > year. Gated had that 4 1/2 years ago. Oh my gawd. Etc etc... > > > > > > RobS > > Gated would dump core like crazy and lose routes and adjacencies 5 > years ago and it does the same now. Well, on the second thought, I > don't think there's any real reason to bitch about it - all the other > free reference stuff (sendmail, inn, etc, etc. Even 4.4) is plagued > with the same problems. And everybody is kind of accustomed to the > status quo. As of data structures - I remember there was a course on data > structures on my first university year. And you know what? I haven't > seen anything new since then - gated or no gated. > > > Let's compare: > > [...] > > Oh. Don't tell my you do all this on your own and don't use some kind of > conf-generating script. > > > Of cource gated.conf is not (in usial revision) so powerfull as IOS, > > but ideas - ideas in gated was great, and gated works well even now. > > Karl Marx's soul to the soul of Friedrich Engels: "Oh yes. But the idea > was b-e-a-u-t-i-f-u-l..." > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > > Dima >

10 12

Re: Cisco as Big Brother (Was Re: Cisco's AIP vs HSSI)
by Michael_Fox＠BayNetworks.COM 21 Oct '96

21 Oct '96

At 02:28 AM 10/18/96 -0500, you wrote: > >In message <199610180717.AAA16438(a)netservice.ca.navigist.com>, "Joe Rhett" writ >es: >> >>> But you can't get one engineer to hack something into the router >>> code for you on just his say-so anymore. But once you could. I dunno >>> maybe you still can, but I think you have to have megabucks behind >>> you to do it. >> >>> Yes, you can, but you have to do it under the table and via direct >>> contacts. And a bottle of cask strength single malt will help. ;-) >> >> >>You know, I find it hard to think of this as a feature - especially >>given the number of times the "quick hack" broke something else. And >>it's always missing the next release of the software. >> >>It takes an Act of God to get Bay to release a fix - but it works when >>they release it, and it works in the next full release too. > >I know of a bunch of very useful things that originated this >way that are in production code on my cisco boxes now. If >sprint had been in a situtation where they need a new feature X >in order to make the network run at all, because no one >had designed they network to grow like it did, I'd hate to have >bought Bay and not be able to get a timely fix. > >I would definately ask my router vendor hard questions about >how quickly a fix will be released assuming I have a "network down" >condition. Bay generally releases fixes every few weeks. For a "network down" situation, if releasing a workspace immediately is the right thing to do, then that's what we do. Who makes the call? The customer, after receiving input from the Bay engineering team. Michael

3 2

Re: Cisco's AIP vs HSSI
by Tony Li 21 Oct '96

21 Oct '96

But I like PPP because cisco still doesn't document their HDLC line protocol. :-) (Go ahead, try to find it online or ask someone on one of the tech support lists to find it for you. :-) What would you like to know? ;-) I'm kidding. Of course I love everything about cisco, since as Dave O'Leary has told me for a long time "Sooner or later everyone ends up working for cisco" and he seems to be right. I beg to differ! ;-) Tony

20 32

Re: GigaRouter (Was Re: Cisco as Big Brother))
by Vadim Antonov 21 Oct '96

21 Oct '96

Alexis Rosen <alexis(a)panix.com> wrote: >Of course I'm not saying that I *Want* to use an HD in this situation; flash >is clearly a big win. In my experience flash is a lot _less_ reliable than HDs. Ciscos losing flash contents aren't that uncommon. >But I don't see how using a floppy or ZIP improves >wins. Floppy doesn't rotate until it's boot time; and in COs dust is not a big problem. So, for a boot device floppy is probably the best (providing it's not an el cheapo device). An additional benefit is that it's easy for field personnel to handle. --vadim

2 1

Re: GigaRouter (Was Re: Cisco as Big Brother))
by Rob Liebschutz 21 Oct '96

21 Oct '96

> Michael Dillon writes: > > You can also try building a machine with a boot device like the 2.88 > > megabyte floppies. Using the same techniques FreeBSD uses for their boot > > disks, you can decompress the boot floppy into a large RAMDISK and run > > that way. Or simply use a ZIP drive for the boot device but run from RAM > > as before. It's not as good as 100% solid state but it comes pretty close. > > This isn't clear to me. Why do you assume a ZIP is likely to be more reliable > that a hard disk? ZIPs haven't been around long enough to be sure of this, > and HDs are pretty reliable these days. > > Of course I'm not saying that I *Want* to use an HD in this situation; flash > is clearly a big win. But I don't see how using a floppy or ZIP improves > wins. > > FWIW, I suspect that building a 1.4MB fs that can boot and then nfs-mount > (or ftp to a memory fs) needed binaries would be not a lot harder for FreeBSD > or BSDi than it was for NetBSD. Not really, the BSDI installation procedure does it with one floppy. The BSDI bootstrap knows how to load a gzipped kernel image. I've made modified boot disks from their installation procedure. I've never turned on NFS though, and admittedly it's all packed in there tight enough that every time I want to do something else I'm deleting one thing to add another. An 8mb flash card for $300 would be very nice if it worked. Rob

2 1

RE: Windows/NT to break the Internet?
by Hank Nussbacher 21 Oct '96

21 Oct '96

On Fri, 18 Oct 1996 11:16:28 -0700 Peter Ford wrote: > >Hank, > >Have your tried to replicate your customer's problem? We have tested >setting the prefix mask in the IP stack in NT 4.0 and it can be set to >prefixes longer than 24. > >cheers, peter I have to apologize for the lack of clarity since I was getting the reports from customers. The problem is NOT in setting a prefix mask. The problem is with inverse for subnets. From the install notes of Windows/NT (DNS and Microsoft Windows NT 4.0) dated May 12, 1996 (page 28), under the section 'Configuring Reverse Lookup' the doc says, and I quote: ??? I haven't a clue. I think there is a bug??? end quote. The defacto standard for doing subnetting and inverse has been documented in a draft standard: ftp://ietf.cnri.reston.va.us/internet-drafts/draft-ietf-cidrd-classless-inaddr-00.txt I hope Microsoft can get this fixed since I have had to start allocating /24s to very small sites in order to bypass this problem. Hank

1 0