September 1997 - Test - lists.nanog.org

Re: need contact info
by Sean Donelan 17 Sep '97

17 Sep '97

>Of course, he neglected to mention, "Good luck getting a straight answer >about anything from MCI. You're better off calling your psychic if you >have a network problem involving MCI." Actually InternetMCI has improved a lot since I started dealing with their employees in early 1995. They still have several annoying habits though. But MCI is not unique. Keeping up-to-date contact information is a problem for lots of providers. Unfortunately, you don't realize the contact information doesn't work until you need to use it. Only then do you discover the provider only has a 1-800 number which isn't callable from your area, you can't send them e-mail because the network isn't working, and the contact page on their web server doesn't load. So once again, I ask all providers to please check your own contact information in the WHOIS database (I know it ain't much, but often its all we have) for an up-to-date e-mail address and internationally diallable telephone number. If you don't want to list your NOC, please list a contact that knows what a NOC is, and can reach your NOC. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re[2]: Traffic Engineering
by pkavi＠pcmail.casc.com 17 Sep '97

17 Sep '97

Good point re the changing patterns over time. Traffic engineering is not a one time activity, but something you should expect to do once a quarter. Measurement, trendline analysis, projections, and verifying the accuracy of the projections, and determining the reasons for inaccurate projections are all important parts of the process. In this way, traffic engineering is akin to writing a company's business plan--a dynamically changing document that helps you make decisions, rather than set in stone and oblivious to the outside world. Prabhu ______________________________ Reply Separator _________________________________ Subject: Re: Traffic Engineering Author: "Kent W. England" <kwe(a)geo.net> at smtplink Date: 9/17/97 10:19 AM At 09:59 AM 9/17/97 -0500, pkavi(a)pcmail.casc.com wrote: > > As a former network design guy who's done traffic engineering and > design (and redesign) on many networks (Internet and otherwise), I > disagree that traffic engineering doesn't work for the Internet. > Prabhu; Thanks for the treatise on network engineering. I agree that network engineering is useful and that there should be traffic engineers. However, the engineering managers must not forget to see the forest for the trees and must heavily discount the traffic engineering studies, when faced with out-of-the-box data. Here are some examples: > 2. Identify which % of traffic, if any, has regional locality. > For pure Internet traffic, the probability that the source and > destinatino of traffic are within the same metropolitan area > tends to be low (10% or lower for metros within the US). This is true only so long as the density of the Internet is low. This is so because so long as the density is low, few of your neighbors will be on the Internet and therefore local issues are irrelevant. However, at some point, the density of the Internet gets to a critical point, say 30% to 40%. At that point a pizza parlor owner says to himself "two out of every five of my customers are on the Internet. Perhaps I need a web page." And, suddenly, pizza on the Net makes a lot of sense and the traffic patterns shift. As the density grows to 90%, local traffic becomes dominant over distant traffic. Another example is distributed web hosting. When distributed web hosting takes off, your backbone will be heavily discounted and your peripheral interconnect bandwidth will be woefully short. Web traffic will zoom as performance dramatically improves, but your backbone bandwidth will drop. That breaks your traffic model. So, by all means, do your traffic studies, but be prepared to throw them out or re-write them when the environment changes. Then throw bandwidth where it will do the most good. :-) --Kent

1 0

Route Flaps at NAP's
by ramesh＠cs.ucf.edu 17 Sep '97

17 Sep '97

I have couple of questions on Route Flaps at NAP's. 1)How often do they happen? (per hour, per day etc) 2)When route flaps occur, on an average how many routes are flapped? Any pointers indicating the above statistics will be helpful. Thanks, -Ramesh

7 7

NANOG topics so far
by Susan R. Harris 17 Sep '97

17 Sep '97

Greetings - here are presentations we've lined up so far for the Oct. 27-28 NANOG: - Update from the IPPM Working Group - Vern Paxson, Lawrence Berkely Lab - Routing Analysis and Tools from the Internet Performance Measurement and Analysis Project (IPMA) - Rob Malan, University of Michigan - Plans for the Internet Routing Registry Transition to Routing Policy Specification Language - Cengiz Alaettinoglu, ISI - Update from IOPS.ORG - Speaker TBA - Freely Available Statistics Reporting Agents: A Practical Review - Stan Barber, Academ Consulting Services - Internet Routing Registry Cleanup Efforts - Curtis Villamizer What other topics would you like to hear about? -------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 313.936.2100 srh(a)merit.edu Senior Science Writer Fax: 313.647.3185

1 0

Re: Traffic Engineering [was Chanukah [was Re: Hezbollah]]
by sob＠academ.com 17 Sep '97

17 Sep '97

> Doing traffic engineering right is hard. The telcos have it down pat > for their voice networks, and telco-based ISPs often have applied > this design expertise to their ISP network. Having a person do > traffic engineering can save the ISP big bucks. I agree that traffic engieering is important and doing it well is hard. However, I can point to many cases that demonstrate that the telco folks don't have traffic engineering down pat for their voice networks. The great majority of the cases show up in two areas: InterCO trunking and Inter-provider (telco-to-telco trunking). Of course, it just may be the telcos I deal with here in Texas. I can't speak of direct experiences with everyone in the country. -- 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.

2 1

Re: need contact info
by James A. Farrar 17 Sep '97

17 Sep '97

At 08:39 PM 9/16/97 -0700, Rick Horowitz - Network Administrator wrote: >Of course, he neglected to mention, "Good luck getting a straight answer >about anything from MCI. You're better off calling your psychic if you >have a network problem involving MCI." > Be nice Rick, our NOC knows what a pleasure its been talking to you. We still have that picture too. Nice touch. -Jim

1 0

Problems configuring cflowd
by Demetrius Christian 17 Sep '97

17 Sep '97

Hello, Im configuring Daniel Mc Robb's and John Hawkinsons cflowd. I plan on running this on Solaris 2.5.1. I had some problems compiling it and then can't seem to get the cflowd.conf config file to be parsed properly. I am using gcc 2.7.2.1 and having problems with lex. I changed ~/apps/cflowd/lexer.lex to include the following: %e 16000 %p 14000 %k 14000 and took out one of blan lines around the '%%' line. I then made some changes to the Makefile and removed the -CF option from lex -CF. After these changes I could compile the software ok. I however keep on getting problems about a left parentheses in cflowd.conf when I try to start the daemon. Has anybody compiled this under Solaris? Did you manage to get it sorted out? If so I would appreciate any assistance to get this running. Many thanks Demetrius !

1 0

Re: need contact info
by Mark Kayser 16 Sep '97

16 Sep '97

As an "MCI" person here is the number to the INOC. :) 919-677-5566 This has been the NOC's number for the past 2+ years. The 800 number if you are interested is 800-977-4662 but to report a problem you should try our ISP group first so that a ticket can be opened to track the issue. Here are the numbers: 281-276-4231 or 800-663-9932 These numbers did just change as this group just moved to Texas. This may have been who you were informed to contact before. Sorry for the confusion. These should be the correct numbers. Hope this helps. --Mark Kayser MCI Technical Support -----Original Message----- From: Sean Donelan <SEAN(a)SDG.DRA.COM> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, September 15, 1997 8:31 PM Subject: Re: need contact info >>> Since NANOG seems to have turned into directory assistance, does anyone >>> know the preferred, listed, international phone number for the MCI NOC, >>> not a 1-800, or 1-888 number. Hopefully a number that will be in service >>> longer than three months. All the non-1800 phone numbers our MCI sales >>> person locate seem to be DID numbers to individual's voice mail or stop >>> working when the person leaves MCI. >> >>919-677-5566 > >Cool, so far four non-MCI people have sent me phone numbers for >MCI. The interesting thing is they each sent me a different phone >number. > > 703-715-7056 > 703-715-7292 > 919-677-5351 > 919-677-5566 > >Anyone else care to play? >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > >

2 1

RE: Physical transport media
by Brian Holt 16 Sep '97

16 Sep '97

I'm wondering if there are any concerns for possible lawsuits arising from people slipping and falling from the use of /dev/null. -- Brian Holt Technical Support Engineer Nap.Net, L.L.C (414)747-8747

2 1

Re: too many routes
by David Paul Zimmerman 16 Sep '97

16 Sep '97

>Some people seem to view CIDR as an opportunity to >subdivide their traditional 'Class B' networks. I would classify >most of these announcements as 'mistakes' because they usually also >announce the supernet, and have the same path. I could see the intentional announcement of both if you've got diverse -- but ultimately equal -- paths into your B. So site X might advertise B.0/17 to normally receive the low half of the address range, site Y might advertise B.128/17 to normally receive the high half, and both sites would advertise B/16 so that if one site went down in that scenario, the other's B/16 advertisement would take over for the failed site's /17. In a normal case, though, you'd see the /16 and /17 with the same path. Does this pattern seem to apply to any of the announcements you see? dp

1 0