- Test - lists.nanog.org

The Cidr Report
by Tony Bates 30 Jun '00

30 Jun '00

This is an auto-generated mail on Fri Jun 30 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 30Jun00 0) General Status Table History ------------- Date Prefixes 230600 80236 240600 80187 250600 80366 260600 80526 270600 80814 280600 80884 290600 80973 300600 80928 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7777 Number of ASes announcing only one prefix: 4376 (2400 cidr, 1976 classful) Largest number of cidr routes: 964 announced by AS701 Largest number of classful routes: 1070 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Jun00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 436 149 287 65.8% BCnet Backbone AS1221 645 445 200 31.0% TELSTRA-AS AS7046 534 360 174 32.6% COQUI-NET PRTC Internet AS9269 183 55 128 69.9% Hong Kong CTI AS9706 152 26 126 82.9% Pusan Metropolitan City Office of AS2609 127 12 115 90.6% EUnet-TN AS9304 122 18 104 85.2% Hutchcity AS7657 293 190 103 35.2% The Internet Group Limited AS7545 153 55 98 64.1% TPG Internet Pty Ltd AS6429 210 118 92 43.8% RDC-INTERNET AS174 563 471 92 16.3% Performance Systems International AS7496 127 42 85 66.9% Power Up AS4293 328 243 85 25.9% Internal ASN for C&W AS705 343 263 80 23.3% ALTERNET-AS AS701 1070 998 72 6.7% Alternet AS577 250 178 72 28.8% Bell Backbone AS724 229 158 71 31.0% DLA-ASNBLOCK-AS AS3908 274 205 69 25.2% Supernet, Inc. AS1727 152 83 69 45.4% MRMS-WEST AS9557 95 28 67 70.5% Pakistan Telecommunication Compan AS3602 304 245 59 19.4% Sprint Canada Inc. AS6595 108 50 58 53.7% DODDSEUR AS5106 88 30 58 65.9% AADS-COLUMBUS AS7568 81 24 57 70.4% C.S. Communications Co., Ltd. AS4740 331 275 56 16.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS3749 112 56 56 50.0% TECNET AS7018 545 492 53 9.7% AT&T WorldNet Service Backbone AS1785 361 312 49 13.6% NYSERNet Backbone AS209 257 209 48 18.7% Qwest Communications AS14562 80 35 45 56.2% UNKNOWN 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: PGP kerserver infrastructure
by Randy Bush 30 Jun '00

30 Jun '00

> What we do have are UI problems for clients. There are some server > problems brought on by not really having much of a protocol to begin with. > There are some server problems that result from having a distributed service > with no tools or protocol to manage those relationships. it is the last one which brought me into this maze of twisty peop^h^h^assages. randy

1 0

RE: PGP kerserver infrastructure
by Eric M. Carroll 30 Jun '00

30 Jun '00

My answer was deliberately naive as Randy alluded to in a follow-up email. When you look at this issue, there are three competing subproblems: 1) How do I find the X server for domain Y that domain Y is running? 1A) How do I find the X server that proxies for domain Y (a subcase of 1) 2) How do I find user Z in domain Y when no server (proxy or native) is available? 3) How do I find user Z in a list of user registries? (and how do I find the definitive list of user registries?) To get a service that scales, you have to eventually get to (1). It is essential. We all agree on this: noone seriously suggests there should be one or a small number of http or email servers. As a network administrator, I (eventually) will want to run (or control the management of) the server, especially if it is critical enough. Clearly, problem (1) can and should use the DNS. And leverage the SRV records. It is the system that can be leveraged that will make the service scale. This implies, in some way, that the service uses user identifiers that are related to the domain name in some way (e.g. email address). One issue is that protocol developers often do not define the mechanism to relate service to DNS name in the protocol spec. People are left to develop it by consensus or not at all (e.g. www.domainname) To be effective, server software developers must implement it as the first action the server takes (although there may be others) so that scaling is gained by default if someone implements the option. Of course, this is necessary, but not sufficient to attracting a user base, to bootstrap the community and reach critical mass necessary to be viewed as a critical service. Thus, option 2 is necessary. A default, global context where I can register my service information on a per user basis (since I don't have a domain specific server in the early days by assumption). If you think of email, for example, we do that all the time too (hotmail, ldap, etc etc). So both solutions are necessary. Its just that new service deployment seems to ALWAYS start with option 2. Then, once you are big, it is a huge problem to change to option 1. In fact, what happens in the wild is option 2 is implemented, then people try to figure out how to instantiate a flat namespace across many user registries (where registration is at the discretion of the user, so there is NO obvious binding between user and registry - anyone ever try to actually find a user of MS Netmeeting?). If the PGP key servers implemented both option 1 and option 2 as a fall-back, then Randy could bang on the people whose keys are mission critical (and he can't get), and encourage them to register their own server. Otherwise, you live with the default. The risk with PGP key servers now appears to be that option 2 was selected, and in trying to scale the system, people are trying to grapple with instantiating a single flat registry instance structure (and operate it on the scale necessary to support per-user registration). Scaling a point user registry without hierarchy is no different than trying to scale a flat network addressing space (and we know how that worked out). If you have many flat user registries, then you have a whole other problem - how do I find user Z across many user-selected registries. And how to I find (and register) the canonical list of registries. That is in effect saying the key to look up user Z is flat - there is no hierarchy. My assertion is that such a system cannot scale anyway, so no point in trying to fix it. To speak to Randy's point - the server structure is different than the key relationships. I believe a PGP key is associated to an email address, right? If so, then what's wrong with first looking in the domain to find the keyserver, and walking up the domain tree? If nothing is found, *then* check the default (flat) user registry? (But I am not a PGP expert, so someone else pick this up if I am wrong). It gives the administrator of domain Y the option of scaling without the problem of figuring how to run a flat registry and restrict it to their community of user Zs and ensure everyone can find user Z in domain Y on server X (which really is not obvious at all). Using the DNS, of course, assumes the service has a server that has a port that can be mapped to srv records... (S/N check: This might be drifting from nanog...) Regards, Eric Carroll

2 1

RE: PGP kerserver infrastructure
by Randy Bush 30 Jun '00

30 Jun '00

> As far as DNSSEC, a trust model following the domain hierarchy is > currently being pushed did dnssec drop cross-auth? cross-auth specifically allows non-hierarchic trust which allows one to 'subvert' the hierarchic model. randy

1 0

Re: Internet Routing Problems
by Aleksi Suhonen 30 Jun '00

30 Jun '00

Randy Bush wrote: > this has been going on for many days. it would be helpful if the folk > making these continuing messes would clean them up so that it does not > prevent those of us who try to make only occasional messes from seeing > our errors (note the last line). This is in fact a prolonged distributed denial of service attack of sorts. > Reserved Network and Host Announcements > --------------------------------------- > 128.88.250.0/27 at Mae-East from BBN-Planet (AS1) ASPATH=1 5727 2915 151 IGP ... > ***** Too many entries. List Truncated! ***** -- Aleksi Suhonen Network Specialist Axu TM Oy http://www.axu.tm/

1 0

Experience with Cybex
by James Smith 30 Jun '00

30 Jun '00

I'm look at purchasing a Cybex KVM switch system (XP4040) and was wondering if anyone had any good or bad experiences to share, or opinions about other similar products. Is Cybex widely used in NOCs? -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People

1 1

Re: PGP kerserver infrastructure and codes
by Richard Irving 30 Jun '00

30 Jun '00

<Ahem> SO, that one joined the -post- list ?

1 0

Re: PGP kerserver infrastructure
by Steven M. Bellovin 29 Jun '00

29 Jun '00

In message <Pine.LNX.3.96.1000629104337.11811B-100000(a)Overkill.EnterZone.Net>, John Fraizer writes: >> > >While I agree with the statement, I take exception to any notion that >_any_ service we provide would be "marginal." Thus far, my network has a >higher uptime percentage than any carrier we interconnect with, period, >the end. We planned, built and operate a regional exchange, including the >route servers, that has been live 24/7 for 11 months. That is 0% downtime >for the route-server platform and the exchange fabric. The issue isn't so much network availability -- though a key server designed to meet the needs of NANOG folks is interesting, since they most need to talk to each other when the net isn't working well -- as service availability. That has all sorts of implications at the application level. --Steve Bellovin

5 5

RE: PGP kerserver infrastructure
by Randy Bush 29 Jun '00

29 Jun '00

> The server network is better with 10 reliable well managed servers than > with 100 marginal ones; in my opinion..... well said. thank you. it was this that led me into this maze of twisty passages. randy

2 1

Re: Illuminet ss7 cable cut (was Re: New York City: ATT Local Service (TCG))
by Steven M. Bellovin 29 Jun '00

29 Jun '00

There's an AP news story on the cut at http://www.latimes.com/news/nation/20000629/t000061595.html --Steve Bellovin

1 0