- Test - lists.nanog.org

Re: Interconnects at NANOG
by Ehud Gavron 03 Jan '96

03 Jan '96

Susan Harris writes: ... >MAE Phoenix, and the Tuscon NAP. Can we agree that there's no longer any difference between MAE, NAP, and Interconnect? [with the exception of ``the four priority NAPs''] Nit: Tucson has the C before the S... Ehud -- Ehud Gavron (EG76) gavron(a)Hearts.ACES.COM * Unsolicited Commercial E-Mail will cost $500/message under USC 47 * * which can be found online at http://www.law.cornell.edu/uscode/47/ *

1 0

208.0.x.x
by Christian Nielsen 03 Jan '96

03 Jan '96

not only are they in the bgp tables, one can even traceroute to them bash# traceroute 208.0.1.5 traceroute to 208.0.1.5 (208.0.1.5), 30 hops max, 40 byte packets 1 slc-t1.eli.ut (206.29.221.1) 3 ms 2 ms 2 ms 2 cir-OC48.a.slc-t1.vii.net (206.29.193.25) 5 ms 3 ms 3 ms 3 border2-hssi2-0.Denver.mci.net (204.70.29.9) 14 ms 14 ms 13 ms 4 core-fddi-1.Denver.mci.net (204.70.3.113) 16 ms 14 ms 14 ms 5 core-hssi-3.SanFrancisco.mci.net (204.70.1.38) 81 ms 183 ms 38 ms 6 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 291 ms 257 ms 337 ms 7 smds.west.cix.net (149.20.64.1) 336 ms 76 ms 41 ms 8 149.20.21.2 (149.20.21.2) 61 ms 116 ms 54 ms 9 santa-barbara.la-frame.imn.net (204.74.127.253) 106 ms 54 ms 54 ms 10 208.0.1.1 (208.0.1.1) 58 ms 61 ms 58 ms 11 208.0.1.2 (208.0.1.2) 58 ms 58 ms 60 ms 12 208.0.1.1 (208.0.1.1) 61 ms 61 ms 61 ms and a traceroute to bash# traceroute 208.0.1.1 traceroute to 208.0.1.1 (208.0.1.1), 30 hops max, 40 byte packets 1 slc-t1.eli.ut (206.29.221.1) 3 ms 2 ms 2 ms 2 cir-OC48.a.slc-t1.vii.net (206.29.193.25) 5 ms 3 ms 3 ms 3 border2-hssi2-0.Denver.mci.net (204.70.29.9) 60 ms 112 ms 108 ms 4 core-fddi-1.Denver.mci.net (204.70.3.113) 134 ms 31 ms 16 ms 5 core-hssi-3.SanFrancisco.mci.net (204.70.1.38) 44 ms 44 ms 37 ms 6 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 42 ms 38 ms 38 ms 7 smds.west.cix.net (149.20.64.1) 48 ms 41 ms 43 ms 8 149.20.21.2 (149.20.21.2) 61 ms 54 ms 54 ms 9 santa-barbara.la-frame.imn.net (204.74.127.253) 54 ms 54 ms 54 ms 10 204.74.97.254 (204.74.97.254) 67 ms 58 ms 58 ms and bash# ping 208.0.1.1 208.0.1.1 is alive what is going on.... bash# telnet 208.0.1.1 Trying 208.0.1.1 ... Connected to 208.0.1.1. Escape character is '^]'. ComOS - Livingston PortMaster login: holly cow, bash# ping 208.0.1.2 208.0.1.2 is alive bash# telnet 208.0.1.2 Trying 208.0.1.2 ... Connected to 208.0.1.2. Escape character is '^]'. User Access Verification Password: which is a cisco... so, someone has gotten around getting ips from the nic and gave them to themselves Christian Nielsen Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 PS :) Private Email christian(a)nielsen.net ********************************************************************* * Unsolicited Commercial E-Mail will cost $500/message under USC 47 * * which can be found online at http://www.law.cornell.edu/uscode/47/* *********************************************************************

2 2

MAE-LA
by bmanning＠ISI.EDU 02 Jan '96

02 Jan '96

Hi, MAE-LA is now active at 4676 Admiralty Way. Expected turn-up at 1 Wilshire is 15 Jan 96. --bill

1 0

Interconnects at NANOG
by Susan R. Harris 02 Jan '96

02 Jan '96

Greetings - at the upcoming NANOG we'll be highlighting activities at several new U.S. interconnection points, including MAE Houston, MAE Phoenix, and the Tuscon NAP. Are there folks out there from other interconnects who'd also like to give a presentation? --Susan Harris

1 0

Routing Arbiter Daily Route Flap Reports
by Sean Doran 02 Jan '96

02 Jan '96

http://www.ra.net/~ra/statistics/flap.html is actually proving to be quite useful. Thanks RA gang. BTW, highlights from the 24 hours of Dec 31st: 1:AS1849 prefixes=159 flaps=5145 2:AS174 prefixes=54 flaps=3239 3:AS1257 prefixes=180 flaps=2987 4:AS278 prefixes=43 flaps=2984 5:AS114 prefixes=77 flaps=2777 6:AS3250 prefixes=68 flaps=2298 7:AS2018 prefixes=25 flaps=1393 8:AS2697 prefixes=25 flaps=1346 9:AS1324 prefixes=3 flaps=1218 10:AS1267 prefixes=16 flaps=1111 13:AS701 prefixes=22 flaps=912 16:AS2551 prefixes=16 flaps=717 19:AS813 prefixes=4 flaps=471 29:AS3561 prefixes=8 flaps=194 57:AS279 prefixes=3 flaps=79 118:AS86 prefixes=1 flaps=19 This is slightly different from what sl-mae-e.sprintlink.net sees, but not enough to make big complaints about, and largely it's because not everyone peers with the RSes. What's really appalling to me is that the top 10 origin ASes -- and in fact, only a tiny handful of prefixes in these origin ASes -- in the list account for 17 flaps a minute, or about 1/9th of the entire flap we were seeing at MAE-EAST alone during the same 24 hours. In practice, it's really only a fraction of these 650 prefixes that cause this amout of flap. Please everyone run bgp route dampening as close to the edges of their networks as much as possible so that individual prefixes like this one: SL-MAE-E>sh ip bgp 204.157.1.0 BGP routing table entry for 204.157.1.0 255.255.255.0,version 590853 Paths: (2 available, best #2, advertised over EBGP) 4200 5696, (suppressed due to dampening) 192.41.177.145 from 192.41.177.145 (205.137.59.254) Origin incomplete, metric 1, localpref 90, valid, external Dampinfo: penalty 10567, flapped 3175 times in 14:25:55, reuse in 0:57:10 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ don't have this amount of flap propagated throughout the Internet (except those bits that run bgp dampening at their edges). While manual fixes are fine and dandy, it just doesn't scale if the only practical tool is the occasional Seanogram to people's NOCs whenever I manually eyeball a really heavily flapping prefix. BGP dampening is well tested and well understood, and will eliminate this particular case of flap, which is to the good of everyone. Sean.

1 0

Re: % of good routes in RADB
by Steve Heimlich 30 Dec '95

30 Dec '95

Gordon, You write: --- On december 14 Elise gerich wrote to the above recipients: Some of the information in the RADB is "historical." It was carried over from the PRDB for purposes of the transition from the NSFNET Backbone Service to the current US Internet Architecture. The RA team has been working with CA*net and ANS to reduce duplicate route objects which are artifacts of the transition. Several months ago, approximately 3000 routes were deleted from the RADB because CA*net worked with us to identify which routes were now being maintained in the CA*net DataBase. Approximately, 1000 route objects have been deleted as a result of a request from ANS more recently. Approximately 20% of the route objects that existed at the time of the transition have been removed. COOK: So when you say 20% of the routes have been removed, how does one judge what remains that is defunct and still remains to be removed???? Of the 80% does anyone have a clue as to whether 95% of the 80% are "good" or whether the real total of good routes might be on 50% of the 80%?? --- One of the interesting things about the Internet Routing Registry (IRR) is that it is really just a database of databases. One of the component databases is the RADB. Other component databases include the ANS database, the CA*net database, the MCI database, and the RIPE database. Some tools which use these databases apply a preference in terms of trust. ANS configuration generation tools, when using the IRR, trust components in order of ANS, CA*net, MCI, RIPE, and the RADB, treating the RADB as repository of last resort in some sense. This is not meant to devalue it as a useful component so much as to apply perspective to the relative integrity of each piece of the system. I believe that there is a natural incentive for providers to keep their own customer routing information up to date. For historical reasons stated above, I think that the RADB in particular is going to be relegated to "last call" status for some time to come. CA*net and ANS have cleaned duplicate or bogus objects from the RADB database, and have replaced them with objects in our respective databases. I'm not sure of the status of MCI's effort in this regard, but we rely on MCI's own (clean) database when handling MCI customers as noted above, so it just doesn't bother me that much. Similarly, because we treat the RADB as last resort, the % of good routes doesn't bother me in any excrutiating way, though of course I'd prefer for it to match reality more than it may today. Multihomed customers are a bit tricky, but for now that can be solved by open communication among providers, or between provider and customer. Some of the tools which make use of the distributed database model are a bit lean, a bit immature. However, improvements will come in time. There are new tools to deal with more realistic aut-num's, new policy specifications to deal with real life ISP policy implementations, and new database code to deal with distribution in several ways. Some are in test, some are in production, but all are improving. It's fair to say that those registries which are more natural and comfortable for folks to use should reasonably be favored over emotionally incorrect or truthfully inaccurate repositories. Personally, I think that some hierarchical system may scale quite well, though deciding the hierarchy will be fraught with the same difficulties as was BGP-1, for example (who's closer to the top?). For now, provider-specific registries, to the extent that there aren't so many, seem to be doing the job in North America (due to natural incentives), while the RIPE registry seems to be doing the job in Europe (due to traditional comfort -- some research abroad may help to clue me in :-) ). My opinion... Steve

3 2

New Mongolian ISP wants to purchase "Internet calendars"
by sgoldste＠nsf.gov 26 Dec '95

26 Dec '95

DATACOM, Ltd. (Data Communications Systems Co., Ltd.) has just brought up a 128 kbps satellite connection via PanAmSat into SprintLink (still waiting on the final SprintLink hookup and config for routing). Until the Internet connection is finished, they will still be doing UUCP dialup to IGC/APC in California. So, please do not inundate them with messages, just yet, as their phone bill will suffer. Anybody who knows of sources of calendars with an Internet theme is invited to send information to Dr. Enkhbat at [e-mail] address below. My guess is that he will use the calendars to let people know about his new service. And, please, take replies off-line, as this request is not on-target, at least not for nanog list. Thanks, Steve >From: enkhbat(a)magicnet.mn >Date: Mon, 25 Dec 95 14:14:47 GMT >Subject: Internet calendars >To: sgoldste(a)nsf.gov > > >Do you know someone who can send for us calendars (desktop, for wall >etc.) with nice pictures about the Internet ? I would like to buy >100-200 calendars and receive it via DHL. > >Enkhbat D >Dr. Dangaasuren ENKHBAT >Director General >DATACOM, Ltd. (Data Communications Systems Co., Ltd.) >Negdsen Undestnii str. 49 >Ulaanbaatar-46 >MONGOLIA >+976 1 312 063 >+976 1 320 210 FAX >e-mail: enkhbat(a)magicnet.mn ================================================================ Steven N. Goldstein , Ph.D. Program Director, Interagency & International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 USA Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV ================================================================

1 0

Re: Do archives of Nanog list exist?
by jgs＠aads.net 25 Dec '95

25 Dec '95

At 9:41 AM 12/22/95, Mark Boolootian wrote: > Does anyone know if the nanog list has been archived any place? I've > poked around Merit without much luck, and majordomo didn't indicate > the existance of any such archives. > > If there are no nanog archives, it would sure be nice if someone (Merit > perhaps) started keeping them. I'm pretty sure that Merit has archives back to '92 or so (when it was the regional-techs list). Maybe someone from Merit would be so kind as to make those archives publicly accessible. --John

2 1

usenet posts of possible interest, just fyi
by kc＠upeksa.sdsc.edu 25 Dec '95

25 Dec '95

Path: sdcc12.ucsd.edu!ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!world!boursy From: boursy(a)world.std.com (Stephen Boursy) Subject: Re: Consumer Report Profile of ISPs Needed [Urgently!] [was Re: ISPs] Message-ID: <DJzp9B.L7A(a)world.std.com> Organization: The World Public Access UNIX, Brookline, MA References: <DHAG3M.86p(a)news.zippo.com> <4b4a46$cqe(a)earth.njcc.com> <DJu7tu.E9u(a)world.std.com> <4bcmqc$aje(a)clarknet.clark.net> Date: Fri, 22 Dec 1995 13:24:46 GMT Lines: 72 Xref: sdcc12.ucsd.edu alt.internet.media-coverage:4682 alt.journalism:15203 news.admin.policy:24569 alt.culture.usenet:9056 alt.wired:15519 alt.internet.access.wanted:23251 In article <4bcmqc$aje(a)clarknet.clark.net>, John Pike <johnpike(a)fas.org> wrote: >boursy(a)world.std.com (Stephen Boursy) wrote: > >> But in regards to what we're discussing with some ISP's every >>day is Mothers Day--with others Prime Time is always mothers day and >>that is fraud pure and simple. A consumer has a right to get the >>services they've paid for. Everyone has a bad day--that's not what >>we're talking about. > > >What "we" [I hope, I guess] are talking about is the folks who are doing >reporting on ISP's doing a bit of coverage pointing out that this is not >a commodity [ie, non-quality differentiated] market, and that there is >more to evaluating an ISP that just price. The fundamental problem right >now is that just about all that consumers have to go on *is* price, so >that is what the ISPs are competing on, which means that they are selling >service at below cost and trying to make up the losses by increasing >volume [with predictable results...]. > I fully agree. Almost all advertising and most 'reviews' are focused exclusively on price. But the point is that if an ISP oversells and cannot provide what they've advertised they're committing consumer fraud which is quite serious. Others are honest and keep well ahead of consumer demand. An honest business does not sell resources it does not have. >And it seems to me that the second thing that needs a bit of research and >reporting is some sorta buyer's guide on how to choose an ISP -- what >sorta questions to ask and what sorta answers to look for. Right now, >this is limited to pretty much asking the monthly charge for dialup >SLIP/PPP, whereas the more interesting questions relate to things like >"how many customers do you have per modem?" or "what sorta redundancy do >you have on your news-server?" or "[fill in the blank -- I am just a >GUIdiot so I don't really know what to ask.....]?" > Very much needed. I think the best reviews would be accomplished by purchasing accounts as consumers and testing and comparing them--response times and quality for service, problems with connection, time taken to deliver mail, news group availablity and most importantly the speed of the system--a user should never have to wait. >The question of quality-differentiation is going to become increasingly >acute over the next year or two, as the bigger telecos start to move in >on this market and the market starts to differentiate between [for >instance] email/usenet/WWW *access* providers and WWW host providers >[perhaps]. Naively, as soon as Bell Atlantic offers dial-up SLIP, I would >guess that everyone would just go with The Phone Company, assuming that >if they can provide POTS they can provide SLIP/PPP. > And that will also ensure much greater regulation I would imagine. This could be very bad (ala Exon) or very good (ala Nader) but it's coming regardless and it'll probably be a mixture of both. As large regulated industries jump in (cable tv and phone companies) the playing field will change drastically. This will hopefully lead to some sort of universal access as well where consumers are guarenteed a basic tier of services as with phone and cable and will also lead to a bit more of a system of due process and appeal before there can be plug pulling and content based cancels which presently are the most serious problems in this business. Steve

1 0

Do archives of Nanog list exist?
by booloo＠cats.ucsc.edu 23 Dec '95

23 Dec '95

Does anyone know if the nanog list has been archived any place? I've poked around Merit without much luck, and majordomo didn't indicate the existance of any such archives. If there are no nanog archives, it would sure be nice if someone (Merit perhaps) started keeping them. thanks, mb

2 1