- Test - lists.nanog.org

Anyone using?
by Timothy Brown 01 Nov '99

01 Nov '99

Nortel has a box called a Versalar Switch Router 15000. Is anyone using this in a production network? I am particularly interested in performance information. Regards, Tim -- Timothy Brown tim(a)tux.org

4 4

RE: Anyone using?
by Chris Flores 31 Oct '99

31 Oct '99

Simon, You missed the question. Timothy is interested in finding companies who have deployed the latest generation of edge devices. These devices specialize in QoS, VPNs and more intelligent(CPU intensive) features. A GSR is not in the same classification since this router is meant for the core. Vendors competing in the edge space are Shasta, Ennovate, Cosine and Unisphere to name a few. CF -----Original Message----- From: Simon Lockhart [mailto:simonl@rd.bbc.co.uk] Sent: Friday, October 29, 1999 5:19 AM To: Alex P. Rudnev Cc: Timothy Brown; nanog(a)merit.edu Subject: Re: Anyone using? >Let me change your question a little... > >Most hw vendors announces now intergared router-switches (CISCO >NORTEL, etc); usially it is very fast but limited-features devices. > >The question - is anyone using such devices in the production networ? In >the ISP network? We were close to getting some for our network, but were unable to get any hard facts about people who are using them as "backbone" or "border" routers. In the end, we've decided to go with Cisco GSR's. The flaws we tended to find were with not enough enough memory to hold full routing tables, or a limit on the number of route entries. Another flaw was mentioned with regard to the route caching - something about needing to hold in table of which IP addresses were on which port (usual switch behaviour). Simon -- Simon Lockhart | Tel: 01737 839676 Senior R&D Engineer, Online | Fax: 01737 839665 BBC Research & Development | Email: Simon.Lockhart(a)rd.bbc.co.uk Kingswood Warren, Tadworth, Surrey. | URL: http://www.bbc.co.uk/rd/

4 3

Reminder: RPSL Transition
by Gerald Andrew Winters 29 Oct '99

29 Oct '99

A final reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net and email submissions to auto-ripe181(a)radb.net. In addition, between 11/1/99 and 1/1/00, RIPE-181 submissions will be auto-converted and folded into the RPSL database. Users need to be aware of this, as corresponding RPSL entries will be overwritten with the auto-converted RIPE-181 objects. You will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. During the changeover, the whois.radb.net DNS entry will be changed to point to the production RPSL database. Because of DNS latency, there will be a period of time when all resolvers have not received the new DNS entry IP address. During this transition period, some users may want to manually configure the IP address used by their query tools. The IP addresses of the machines will be: whois.radb.net 198.108.0.18 (RPSL queries) whois-ripe181.radb.net 198.108.0.11 (RIPE-181 queries) For further information about the transition to RPSL, see: http://www.radb.net/announce.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

The Cidr Report
by Tony Bates 29 Oct '99

29 Oct '99

This is an auto-generated mail on Fri Oct 29 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Oct99 0) General Status Table History ------------- Date Prefixes 221099 65598 231099 65493 241099 65535 251099 65586 261099 66128 271099 65317 281099 65520 291099 65524 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 100.0.0.0 from AS2561 *** Bogus 110.30.236.0/24 from AS577 *** Bogus 126.0.0.0 from AS2561 AS Summary ---------- Number of ASes in routing system: 5916 Number of ASes announcing only one prefix: 3138 (1731 cidr, 1407 classful) Largest number of cidr routes: 601 announced by AS701 Largest number of classful routes: 1017 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Oct99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 144 239 62.4% BCnet Backbone AS7046 426 255 171 40.1% UUNET-CUSTOMER AS2609 128 8 120 93.8% EUnet-TN AS6944 133 18 115 86.5% RapidSite, Inc. AS1221 625 515 110 17.6% TELSTRA-AS AS9269 131 30 101 77.1% Hong Kong CTI AS7657 250 162 88 35.2% The Internet Group Limited AS174 563 476 87 15.5% Performance Systems International AS577 265 180 85 32.1% Bell Canada Backbone AS4293 227 142 85 37.4% Internal ASN for C&W AS7545 140 64 76 54.3% TPG Internet Pty Ltd AS3749 140 64 76 54.3% TECNET AS7496 111 37 74 66.7% Power Up AS4200 183 110 73 39.9% AGIS (Apex Global Information Ser AS701 1017 954 63 6.2% Alternet AS209 321 268 53 16.5% Qwest Communications AS4740 339 287 52 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS816 226 181 45 19.9% UUNET Canada (ASN-UUNETCA-AS4) AS4755 109 68 41 37.6% Videsh Sanchar Nigam Ltd. India AS2493 132 92 40 30.3% iSTAR Internet, Inc. AS9304 54 15 39 72.2% Hutchcity AS6528 45 7 38 84.4% WORLD-LYNX AS549 213 175 38 17.8% ONet Backbone AS1 501 466 35 7.0% GTE Internetworking AS7568 47 13 34 72.3% C.S. Communications Co., Ltd. AS6172 143 110 33 23.1% HOME-NET-1 AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) AS1785 237 205 32 13.5% NYSERNet Backbone AS9453 33 2 31 93.9% Soongsil University For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

I need someone clueful at Network Solutions
by Ehud Gavron 29 Oct '99

29 Oct '99

Operational help needed. Must register DNS server. Money available. Help? Details below. Note that the more you read the stupider you will get. Ehud Facts: I own WETWORK.NET, registered with the register.com registrar. I own LETOH.COM, registered with network solutions registrar. 20-oct I register a domain LETOH.COM with network solutions, and attempt to use the nameserver "server.wetwork.net" which is under my register.com domain wetwork.net. Network solutions says to [NIC-991020.1545c]: ERROR: Name Server <SERVER.WETWORK.NET>is not registered with InterNIC. 20-oct I send in a host template [NIC-991020.15848] but NetSol says: The <WETWORK.NET> domain is non-existent. First register this host through the host registration process or choose a different name-server. AT THE SAME TIME I get another mail message from them: All Host Forms must be submitted from the e-mail address of the current host contact...we have sent a notification message ... which they did not send anywhere I can tell. 22-oct I sent mail to help(a)internic.net and asked them to fix this. 26-oct Netsol says: The problem with your HOST registration was that you were trying to register a host but the TOP-Level part of the host is not a registered domain, i.e.WETWORK.NET. 26-oct I wrote netsol and said: Wetwork.net exists.. just not with your registry. However, I wish to use mail.wetwork.net as a DNS server with your registry future domains. Please register the host asap. 27-oct Help(a)internic.net says to send in a host template and includes one in the message... 27-oct I submit the host template [NIC-991027.75ef]. I also follow it up to help@ with: 991027.75ef duplicates 991020.15848 as per your request. 27-oct Once again I get the 'All host forms must be submitted from the email address of the current host contact...' 27-oct I forward the mess back to help@internic [NIC-991027.14981] I forward a copy to kimh@ with header Subject: 1. I submit host form. 2 you reject it. 3 I ask for help. 4 help says submit host templte. I DO. Here's the rejection again. Please fix 27-oct help@ responds with: Thank you for contacting Network Solutions. To register a domain name in the COM, NET, ORG, and EDU top-level domains, you should: 1. Make arrangements for Internet service. A company that can connect you to the Internet Ehud Gavron ACES Research, Inc., an RMI.NET company

1 0

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

Prabhu -- > You continue to dismiss concepts (traffic engineering) that have proven > themselves in practice in large networks. And they continued to prove > themselves long after you predicted they would not (years ago). I continue to tell that there are simpler and more robust solutions to the same problems. And that it is much easier is not to create problems in the first place than to think up clever patches later. > Stating the obvious, "there's more fiber in the ground than all routers > can fill up" is not the point. The point is could we have built the Internet > to its present point without traffic engineering? The answer to that is a > resounding NO! If you consider Internet in its present shape working, i beg to differ. It's a horrible kludge which nobody really understands. It's extremely brittle. For one, i'm working for a company which takes the question "How can you put 911 service on the Internet" very seriously. If you look at the things from this perspective you'll see that we have a long way to go, and that making things even slightly more complicated than the bare necessity is not the right way to go - if we want to have it debugged in less than 100 years it took for telephony to become dependable. > The next question is whether traffic engineering is useful for the future. I see little use in discussing the present :) > Remember these practitioners do not build networks based upon theory, but on > practical implementations that prove themselves to work. Perhaps the > load-sharing mechanism you described for Pluris will work. Perhaps not. Works in Cisco's CEF. > But to promote what hasn't proven itself and dismiss what has sounds > suspicously like bad marketing dressed up in the language of mathematics. I do not do marketing. I do not speak for Pluris. If you checked the website you'll see that the company is doing all the TE bells and whistles you find in any other router box. In fact, if i behaved like a marketroid, i'd insist on doing them - because not providing something which is in vogue never wins a lot of customers. As for mathematics and logic reasoning - please, if you see flaws in the reasoning, pount them out. The fact that something sometimes works doesn't prove anything. Following that line of argument, we all should be doing X.25 - because some decade ago that was what nearly everyone was doing and the networks in their present shape at the time couldn't be built without it. --vadim

2 1

Re: Questions about the new RADB Maintainer Fee (FAQ available)
by Sean Donelan 28 Oct '99

28 Oct '99

A note on the FAQ. BGP peering with the route servers does not mean you have to actively announce or listen to any routing information via the route servers. Some providers have used null BGP sessions, or announced routes only to the route servers for some academic-types to study; but not for peering with other providers.

2 1

RE: ** ANNOUNCE -- New RADB Fee Structure **
by Richard Jimmerson 28 Oct '99

28 Oct '99

On Wed, Oct 27, 1999, David Kessens wrote: >On an additonal note: ARIN recently setup an RPSL compatible IRR >registry which might look like a very attractive alternative for those >people that are currently using the RADB ... Thanks, David. ARIN does offer a routing registry which uses RPSL and we would like to encourage everyone to make use of this free service. Please visit the following URL for more information: http://www.arin.net/rr.htm Regards, Richard Jimmerson American Registry for Internet Numbers (ARIN)

1 0

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

> You miss the point. As you well know, capacity is where it is, and not > where you need it. This is a pragmatic and practical problem that costs > people Real Money. Tony, there's more fiber in the ground than all routers together can fill up. And putting in fiber is not a highly skilled labour, quite unlike getting tons of buggy software to work in a production network. > I know one very large backbone operator who says something like "We couldn't >even begin to build our network without TE. It works and we must have it." Isn't it the same provider who's notorious for ATM-based network? If we think of the same provider - i had a pleasure of being a customer. Never again. > It's got nothing to do with latency and everything > to do with capacity. If you have the luxury of having fiber wherever and > whenever you want it, well, you're lucky. But not everyone is quite so > lucky. Luck is 99% a foresight. > I would claim that those _ARE_ real benefits. Numbers? > Perhaps it's not the elegant, desireable, or theoretically beautiful > solution. But it is a practical solution. Yes, sure. As Milo used to say: "With enough thrust even pigs will fly" :) > If you would like to wait for the elegant, desireable, and theoretically > beautiful solution, please be my guest. Those of us who engineer to reality > have more work to do. ;-) I'll simply remind you that there is also a > group of people waiting for the elegant, desireable, and theoretically > beautiful inter-domain routing protocol. I found that one cannot do IDR protocols for a living. Maybe, Yakov :) > Or..... it could be a requirement posed by the customer base that vendors > are trying to address. Yeah, sure. Like the conFusion. Or 7000 series. > You may not share in the problem. That's fine, I don't think anyone would > (ethically) suggest that you use a tool that solves a problem you don't > have. Unfortunately, the tool does not come free - any new code in a box makes the box flakier. And costlier. So what all these features do is shifting cost from those who screwed up network planning to those who did it properly, but have to pay for all bundled TE stuff and live with flaky complicated code. My memories of being dragged out of bed nearly every night because of router software being stuck in interesting ways are not particularly fond. I'll exchange complicated ultra-smart hot stuff for a dumb box which actually works - any time. --vadim

3 2

Re: Traffic engineering tools
by Vadim Antonov 28 Oct '99

28 Oct '99

Traffic Engineering is like Quality of Service - it doesn't create any more bandwidth by magic, and simply reallocates existing resources differently. That established, we have two courses of action - the first, is to bulild overcomplicated networks and then try to fix resulting suboptimal routing with TE. The second option is to simplify topologies by replacing clusters of routers with scalable and inherently fault-tolerant devices (guess which ones i have in mind :) In a long-distance backbone where routers connected directly to fibers, and where there's no overlay of level-2 topology, the cost of deliberate misrouting (sending packets down paths different from shortest) is simply too high to justify any benefits it brings. The intermediate virtual circuit layers simply obscure the fundamentals by making paths inherently non-optimal (if you do not plan to use SONET or ATM VCs to create topologies which do not match physical paths, why whould you want to install it?) Note that customers do not generally care about bandwidth. The name of the game is latency at a given load. Misrouting packets simply increases latency. So. Benefits of TE as compared with simpler and more robust techniques (such as adequate provisioning and capacity planning :) weren't demonstrated in practice. I have yet to see any real backbone operator saying something like "we've got 30% less latency because we do TE". I strongly suspect that is because there are no real measurable benefits - and that TE is being used mostly to cover up planning problems and as a short-term fix to idiocies at a transmission level. That is a very thin justification for replacing technology which is known to work with a very new can of worms. My personal theory on QoS and TE hoopla is that this is a FUD tactics used by Cisco to raise entry barriers for other vendors - and to con customers into buying more of their irrelevant ATM stuff. --vadim PS There were tons of research and articles on best methods of CPU and memory scheduling. In restrospective, building faster processors turned out to be the soultion. Even if they're 99% idle. Meanwhile, the vendors which were keen on doing detailed accounting stuff nearly all are history by now. >From: Jerry Scharf <scharf(a)vix.com> ... >I do believe that some of the TE folks are punting the general case >solution by only attempting to do TE and protection on a small potion of >their traffic. If you have a glut of web traffic that acts as a sponge, >you can get away with nonoptimal management of the subset without causing >meltdowns.

2 1