- NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 20 Oct '00

20 Oct '00

This is an auto-generated mail on Fri Oct 20 12:00:00 PDT 2000 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 20Oct00 0) General Status Table History ------------- Date Prefixes 131000 88713 141000 88736 151000 88773 161000 88779 171000 88976 181000 89084 191000 89049 201000 89411 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 8803 Number of ASes announcing only one prefix: 5049 (2823 cidr, 2226 classful) Largest number of cidr routes: 930 announced by AS701 Largest number of classful routes: 1133 announced by AS701 1) Gains by aggregating at the origin AS level --- 20Oct00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 431 152 279 64.7% BCnet Backbone AS1221 590 439 151 25.6% TELSTRA-AS AS816 595 454 141 23.7% UUNET Canada (ASN-UUNETCA-AS4) AS9269 177 46 131 74.0% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS9304 130 17 113 86.9% Hutchcity AS6429 222 112 110 49.5% FirstCom Internet AS7545 159 55 104 65.4% TPG Internet Pty Ltd AS8013 467 364 103 22.1% PSINET-CA AS7046 355 254 101 28.5% UUNET-CUSTOMER AS4755 200 101 99 49.5% Videsh Sanchar Nigam Ltd. India AS705 356 259 97 27.2% ALTERNET-AS AS7657 313 220 93 29.7% The Internet Group Limited AS7496 126 35 91 72.2% Power Up AS174 539 453 86 16.0% Performance Systems International AS4293 341 259 82 24.0% Internal ASN for C&W AS13999 91 9 82 90.1% UNKNOWN AS701 1133 1052 81 7.1% Alternet AS6595 137 56 81 59.1% DODDSEUR AS3908 251 172 79 31.5% Supernet, Inc. AS577 249 176 73 29.3% Bell Backbone AS724 220 153 67 30.5% DLA-ASNBLOCK-AS AS7018 574 508 66 11.5% AT&T WorldNet Service Backbone AS5106 100 37 63 63.0% AADS-COLUMBUS AS226 168 106 62 36.9% USC/Information Sciences Institut AS3749 121 61 60 49.6% TECNET AS16758 63 6 57 90.5% UNKNOWN AS8151 181 126 55 30.4% UNINET-MX AS8895 97 43 54 55.7% Saudi Arabia AS AS7568 78 24 54 69.2% C.S. Communications Co., Ltd. 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

Re: decreased caching efficiency?
by Simon Leinen 20 Oct '00

20 Oct '00

>>>>> "ld" == Lincoln Dale <ltd(a)interlink.com.au> writes: > caches exist for multiple reasons -- > [1] to make things faster > [2] to save bandwidth > [3] to achieve more "goodput" in network transactions. > [4] to operate at layers-8 and 9 (filtering) [...] > in many cases, people significantly underestimate the effect of #3 - > and it isn't easily measured. it is the effect of a "good" tcp stack > cutting down end-to-end tcp retransmissions when the "last mile" hop > is congested. Not just when it is congested... whenever the proxy (I'm deliberately not talking about "caches"---even a cacheless proxy would have this effect) has RTTs to the origin server and the browser which are both lower than the "e2e" server<->browser RTT, then the TCP control loop will react faster to changing network conditions. This includes faster "ramping up" to available bandwidth, and higher achievable throughput if the same window size is used. Note also that proxies can affect goodput adversely, for example when both the origin server and browser host support larger TCP window sizes than the proxy. This artificially limits throughput when there's little or no congestion over paths with high RTT. I think this is quite common because it is easier for browser hosts than for proxies to support larger TCP windows---proxies have to support high numbers of concurrent TCP connections, and using large windows may incur very significant kernel memory overhead unless OS developers do clever memory-allocation things. -- Simon.

2 1

RE: the new 6509 OSR
by baburn - Bart Burns 20 Oct '00

20 Oct '00

My understanding is that the ESR will serve as high-density aggregation for traditional WAN circuits. 56Kb to DS-3. The OSR will serve as high-density aggregation for DS-3 ot OC-192. Bart Burns Network Engineer Acxiom Corporation (501) 342-4167 email bart.burns(a)acxiom.com -----Original Message----- From: Neil J. McRae [mailto:neil@COLT.NET] Sent: Thursday, October 19, 2000 9:35 AM To: baburn(a)acxiom.com Cc: nanog(a)merit.edu Subject: Re: the new 6509 OSR I thought that the ESR was the new 75xx class box? Regards, Neil. [Charset iso-8859-1 unsupported, filtering to ASCII...] > We are about to purchase several of these OSR's. Here is what we know about > the OSR. If you look at the roadmap for the OSR, Cisco is positioning this > platform to be the next 75xx class device only it will be for high-speed > connectivity at DS-3 or greater. It will scale all the way to OC-192 or 10 > Gig Ethernet. The main reason we are looking at the OSR vs a plain jane > 6509 is because the OSR can serve as a high-speed ingress point to the MPLS > backbone that we are about to deploy. The OSR interfaces have deeper > interface buffers than the plain 6509. > > Bart Burns > Network Engineer > Acxiom Corporation > (501) 342-4167 > email bart.burns(a)acxiom.com > <<Bart Burns (E-mail).vcf>> [Attachment, skipping...]

3 2

Re: decreased caching efficiency?
by Scott Gifford 19 Oct '00

19 Oct '00

All of these problems are solvable, using common and well-known techniques: Daniel Senie <dts(a)senie.com> writes: > It might be worth thinking about the problem from the other end. From a > web site owner's perspective, caching is a major annoyance. Here are the > arguments you may encounter from a web site owner or web developer: > > 1. It interferes with content in many cases (web site visitors may see > cached pages instead of current content). I know cache products claim > this doesn't happen, but it has, and often. Most (all?) reasonable caching products will honor whatever expiration information you put in the page, such as the Cache-Control header and Expires header. Where I've made careful use of these, I've never had problems with stale content, even from browser caches. > 2. The website owner loses information on how many visitors are coming > to the site. A common technique to just count Web page hits is to <img src> a small image on the page, and then use that to count page visits, or to have the page itself not be cacheable, but the images (which are most of the load time) cachable. Having the page itself be dynamic and uncachable, while the images can always be cached, can be a big win all around; dynamic images are fairly rare (except from MRTG. :) ) > 3. The website owner loses the demographics on where visitors are coming > from, and especially the number of unique visitors. (It's not helpful to > know that one cache engine visited, if that cache engine equated to > 10,000 visits in an hour). You can use the X-Forwarded-For header that many caches provide to gather this same information. In the future, you may be able to use the protocol described in RFC 2227 to get more detailed information. > 4. Banner advertising may or may not display properly when caching is > involved, thereby costing the website money. I've never experienced this; I've been viewing the Web through a cache or a hierarchy of caches for 2 years now, and I've never noticed anything weird with banner ads. At least nothing an "Expires: 0" wouldn't solve. > 5. There's NOTHING in it for the website owner, other than the > possibility that SOME pages might display faster for SOME users. > > If folks running networks really think website designers and owners > should care about caching, then there needs to be some sort of benefit > (perhaps paid in dollars) to those affected. Otherwise, there's little > reason for them to care. I don't understand this; having Web pages which are effectively cached around the world reduces the load on your servers significantly (especially as more and more ISPs start to cache), and saves you significant bandwidth. This lets you buy fewer servers for your farm, and buy less upstream bandwidth. Right now, having a site which is cache friendly can save you money in a big way, at the same time savin ISPs money, making your page display how you want it (since the ISPs are already deploying caching, whether your pages are friendly to it or not), and having the page load faster for quite a few users. How is that not a benefit? How is that not paid in dollars? In the future, if Webserver operators would take effective cache performance while maintaining correct display into account when configuring their servers, and make sure that page designers do the same, that would allow caches to become more ubiquitous, and push people to set up large-scale cache hierarchies. It could get to the point where all of the non-dynamic content from an infinitely large Website could be served by an old desktop computer over a 28.8 modem, since it would just have to send its content once to the UUNet cache, once to the MCI/Worldcom cache, once to the Sprint cache, etc. Of course, that's still a ways off. :) Just my 2 cents, ------ScottG.

1 0

Re: decreased caching efficiency?
by Adrian Chadd 19 Oct '00

19 Oct '00

On Thu, Oct 19, 2000, Marshall Eubanks wrote: > Not every body likes spy-ware : > > http://www.buzzwaves.com/article.pl?sid=00/10/18/1325217&mode=thread * I hardly consider a gif on a website spyware, considering that the rest of the webpage contains gifs that would return just the same information and * Thats with email, not web. With web, you request a page which contains images. With email, you request a piece of email. If the email manages to escape its little email sandbox, thats the fault of the people who wrote the client. "spyware" is the wrong term here. "improving client access times" and "decreasing bandwidth requirements" are the right terms here.. Adrian -- Adrian Chadd "It was then that I knew that I wouldn't <adrian(a)creative.net.au> die, as a doctor wouldn't fart in front of a dying boy." -- Angela's Ashes

1 0

RE: the new 6509 OSR
by baburn - Bart Burns 19 Oct '00

19 Oct '00

We are about to purchase several of these OSR's. Here is what we know about the OSR. If you look at the roadmap for the OSR, Cisco is positioning this platform to be the next 75xx class device only it will be for high-speed connectivity at DS-3 or greater. It will scale all the way to OC-192 or 10 Gig Ethernet. The main reason we are looking at the OSR vs a plain jane 6509 is because the OSR can serve as a high-speed ingress point to the MPLS backbone that we are about to deploy. The OSR interfaces have deeper interface buffers than the plain 6509. Bart Burns Network Engineer Acxiom Corporation (501) 342-4167 email bart.burns(a)acxiom.com <<Bart Burns (E-mail).vcf>>

2 1

RE: the new 6509 OSR
by Roeland M.J. Meyer 19 Oct '00

19 Oct '00

I've used them and they are my fav LAN switch, when I can justify the bandwidth. I've installed two in the past 10 months. > rick we will be demoing some of these very shortly - I will > give you any > feedback we collect... > > On Wed, 18 Oct 2000, rick wrote: > > > > > Hi all, > > > > In the UK Cisco are going to release the OSR's in December, > has any one any > > where else used these switches..... I only ask because we > in the process of > > buying a few 6509 and would prefer the higher switching > capacity but I would > > like a few words of wisdom..... > > > > After all Cisco say they are brill, but !!!! > > > > Any advise is always welcome > > > > Thanks > > Richard Smith > > Firstnet > > Leeds > > email: rsmith(a)firstnet.co.uk > > > ************************************************************** > ************** > > ****** > > > > This email and any files transmitted with it are > confidential and intended > > solely for the use of the individual or entity to whom they > are addressed. > > The views expressed in the email and files transmitted with > it are those of > > the individual, not the company. If you have received this > email in error > > please notify rsmith(a)firstnet.co.uk > > > > ******************************************** > > ************************************** > > > > > > -- > In a brood of blind back biting vipers... > ...the one-eyed snake is king! > Rich Sena -.~~~ssssSSSSiSSSSssss~~~.- ras(a)thick.net > > >

2 1

the new 6509 OSR
by rick 19 Oct '00

19 Oct '00

Hi all, In the UK Cisco are going to release the OSR's in December, has any one any where else used these switches..... I only ask because we in the process of buying a few 6509 and would prefer the higher switching capacity but I would like a few words of wisdom..... After all Cisco say they are brill, but !!!! Any advise is always welcome Thanks Richard Smith Firstnet Leeds email: rsmith(a)firstnet.co.uk **************************************************************************** ****** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. The views expressed in the email and files transmitted with it are those of the individual, not the company. If you have received this email in error please notify rsmith(a)firstnet.co.uk ******************************************** **************************************

2 1

MPLS implementation
by Irwin Lazar 17 Oct '00

17 Oct '00

Hi folks, If anyone out there is currently involved in integrating MPLS into service provider networks and would like to present a case study at next year's MPLScon event, please drop me a line. Thanks, Irwin ilazar(a)tbg.com

1 0

Miami
by pete fortman 16 Oct '00

16 Oct '00

I am doing some research on connecting in Miami. Does anyone have an opinion on how well L3 Xroads is doing there? Thanks in advance, Pete Fortman _______________________________________________________ Say Bye to Slow Internet! http://www.home.com/xinbox/signup.html

12 16