- Test - lists.nanog.org

Re: Interconnects at NANOG
by sob＠academ.com 03 Jan '96

03 Jan '96

I think the term "interconnect" is fairly generic. I have often heard some of the providers refer to the MAEs and NAPs as "public interconnects"... However, I think folks use the term "MAE" and "NAP" to refer to different implementations of a "public interconnect"... It is probably an oversimplification to say they are all the same thing. -- 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

208/8 announcements
by Alan Hannan 03 Jan '96

03 Jan '96

I am under the impression that the 208/8 network has not yet been assigned to anyone. It appears we are only up to 207.19/16. However, as someone (Avi?) pointed out earlier: | Cis3#sh ip bgp 208.0.0.0 255.0.0.0 long | BGP table version is 34728, local router ID is 192.35.171.193 | Status codes: s suppressed, * valid, > best, i - internal | Origin codes: i - IGP, e - EGP, ? - incomplete | | Network Next Hop Metric LocPrf Weight Path | *>i208.0.1.0 192.35.171.34 1 50 0 3561 1280 3847 ? | *>i208.0.4.0 192.35.171.34 1 50 0 3561 1280 3847 ? | *>i208.0.5.0 192.35.171.34 1 50 0 3561 1280 3847 ? | *>i208.0.9.0 192.35.171.34 1 50 0 3561 1280 3847 ? | Cis3# Is anyone filtering these routes? From a customer perspective, I think it would be nice if my providers would do so. Or maybe these guys would filter them: | anka:~# whois 3847 | [rs.internic.net] | Internet Media Network, Inc. (ASN-IMN) | 20417 NORDHOFF STREET | CHATSWORTH, CA 91311 | | Autonomous System Name: IMN | Autonomous System Number: 3847 | | Coordinator: | Joffe, Rodney (RJ48) rjoffe(a)IMN.NET | 818-407-0000 | Alternate Contact: | Gibbs, Mark (MG148) mgibbs(a)RAIN.ORG | 818-700-6900 | | Record last updated on 23-Sep-94. | | The InterNIC Registration Services Host contains ONLY Internet Information | (Networks, ASN's, Domains, and POC's). | Please use the whois server at nic.ddn.mil for MILNET Information. | anka:~# I dunno, maybe I should filter them. What are other people doing? -alan

5 8

Re: Interconnects at NANOG
by salo＠msc.edu 03 Jan '96

03 Jan '96

> Date: Wed, 03 Jan 1996 12:03:48 -0700 (MST) > From: Ehud Gavron <GAVRON(a)ACES.COM> > Subject: Re: Interconnects at NANOG > To: srh(a)merit.edu > Cc: nanog(a)merit.edu, GAVRON(a)ACES.COM > > 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... It is probably still appropriate to use the term "NAP" to refer to those interconnect points which are sponsored by the NSF under solicitation 93-52. The solicitation specifies the duties of a NAP Manager organization; read it for details. I believe that the NSF has three or four contracts (Cooperative Agreements to be more precise) in place with NAP Managers for the Sprint, MFS, Ameritech and PacBell NAPs. (I don't know whether Ameritech and PacBell are one or two Cooperative Agreements, although it is probably easy to look it up.) -tjs

1 0

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