- Test - lists.nanog.org

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

Not to beat a dead horse
by Avi Freedman 22 Dec '95

22 Dec '95

But I still see 4 /24s advertised in 208/8: 208.0.1.0 208.0.4.0 208.0.5.0 208.0.9.0 Now, besides the fact that 208.0.4.0 & 208.0.5.0 could be 208.0.4.0/23 (grin), what IS the appropriate way to deal with an ongoing situation where un-NIC-allocated IP space is advertised on the Internet? We have no plans to implement incoming route filters on 208/8 - who knows when the NIC will start allocating out of it. Obviously, having announcements of unallocated address space "work" for the long term is a bad precedent to set. Yes, it can be a pain to deal with the NIC (which is following policies approved of by most NSPs) to get address space, but ... Avi

2 1

Are the Route Servers Viable Solutions That Are Being Held Hostage?
by Gordon Cook 22 Dec '95

22 Dec '95

I am confused - hope I am not the only one. A well respected member of the IETF wrote privately to me: Gordon, what do you think the RR is for? it is a database - why would it have any impact on *if* and under what conditions provider A would want to talk to provider B at a NAP? the NAP rules are *specifically* that peer-to-peer agreements are required, that is one of the reasons the NAPs are level 2 system ----------------------------------- OK - fair enough - I turned next to the routing arbiter web pages listed by bill manning. There I found the following under advantages of using the route servers of the routing arbiter: Quote: Scalable Routing As noted earlier, an ISP's routers on a NAP would need to establish full-mesh BGP peer sessions among themselves in order to exchange routing information without the presence of the RS. That is, if there were N ISPs present at a NAP, each would have N-1 peering sessions. When N is a large number, a sizable load could be placed on each router in order to maintain the required peering sessions and process the needed routing information. With the RS, each ISP only needs to peer with one RS--or two for backup purposes--instead of maintaining N-1 peer sessions. Separation of Routing and Forwarding If a NAP did not have a Route Server, each ISP router would need to perform two major functions at all times: routing processing and packet forwarding. A heavy traffic load could put a substantial extra burden on the routers, which would also need to process routing information. The load would be particularly heavy if the number of peering sessions was not small, the number of destination routes was large, and the policy was complicated. It would be ideal to have the routers concentrate on forwarding packets, and have another system handle routing. The Route Server achieves just this goal: it processes routing information for each ISP's router, thus enabling the ISP routers to concentrate on packet switching. Simplify Routing Configuration Management on ISP's Routers The Route Server processes routing information based on the routing policy defined by each ISP. This includes route filtering, e.g., setting up routing firewalls, selecting the desired path towards all destinations the ISP will be reaching, and other tasks that would normally be configured and implemented on the ISP routers. The RS thus greatly reduces the routing processing, filtering and configuration management load on the ISP routers at the NAPs. Note that RS can facilitate both complex and simple routing policies. For example, a policy could be as simple as to accept all the routes advertised by another ISP at a NAP. Enforce Good Routing Engineering [The text describes how the route server can be used to dampen routing flaps.] End quote. Now it sounds to me like my private corrrespondent was saying that the routing registry was only a data base. That is a source where some could go to ascertain information about someone else's routing. Period. End of discussion. Routing would be done on the basis of bilateral peering agreements between individual providers connected to the NAPs. However, the text I have quoted from the R. ARBITOR'S pages seems to say something quite different - namely that ISP's at a NAP could have a single peering session with the route server there instead of having an individual peering session for every other attached router. If true it seems like this would indeed end most of the strains and stresses on the backbone routers of service providers discussed here several weeks ago under the links on the blink thread. Yet the route server answer won't work if everyone doesn't cooperate with it and provide their routes to it. Bill Manning's nanog post talks with frustration about a large provider that is NOT cooperating with the routing: Many people do register in the IRR. Those that don't, won't for a variety of reasons. For some, there is an unwillingness to trust a thirdparty operator coupled with no desire to run a portion of the registry in-house. When these two conditions are found in a large-scale provider, the concept and implementation of the Internet RR are frustrated to the extent that the non-participating provider becomes increasingly unreachable/understandable. They are relegated to peridoc public postings to mailing lists for definitions of their routing policies. The large scale provider he is talking about, it seems quite clear is Sprint. Question are MCI, PSI, UUNET and ANS in complete cooperation with the Routing Arbiter? Could one effectively run complete peering sessions with each of them and with smaller ISPs by a single connection to a route server?? If the answer is yes and this is not happening what is preventing it? Route Server users could run separate sessions with sprint presumably. Now Bill points out that isps would have to obtain peering agreements with others and that this process would be separate and apart from the operation of the route server which just reflects the individual peering agreements. (So in this sense the private assertion of the IETF figure is also correct.) Is the answer that the router server concept will necessarily fail if it does not get complete cooperation from **ALL** the top tier providers? If so, and IF it could really solve the resource constraints talked about in links on the blink, Sprint's apparent boycott of the concept and its service would seem to be a great shame. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************

6 8

Topics for NANOG
by Susan R. Harris 22 Dec '95

22 Dec '95

Greetings - here are the presentations we're planning so far for NANOG, to be held Feb. 15-16 in San Diego: --Data over cable and the @Home network --Internet traffic and routing studies --internetMCI presentation --IPv6 auto-configuration --New PacBell ATM switch architecture --DVMRP/PIM pilot project --RA update Are there other topics you'd like to hear about? ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------

1 0

Statistics on five interconnection points
by Dun Liu 21 Dec '95

21 Dec '95

The Routing Arbiter collects network statistics at the AADS, MAE-East, MAE-West, PacBell, and Sprint interconnection points. Public available reports include: Ping Delay/Packet Loss (reported monthly). BGP Peering: reports the number of update packets received by route server from each peer, and that peer's down/up information. (daily) System Uptime: reports route server uptime (monthly) Free Virtual Memory and CPU Usage: report the usage of virtual memory and CPU at route servers (daily). More reports will be added, such as tcp data packet retransmission, which will be compared to the ping packet loss The reports are at http://www.ra.net/~ra/statistics/ Comment are welcome. The entire work is the effort of Dun Liu, Bill Norton, Susan Horvath and Susan Harris. Dun Liu

1 0