March 1994 - routing-wg - mailman.ripe.net

Re: SURFnet CIDR announcements
by jimi＠dxcoms.cern.ch 29 Mar '94

29 Mar '94

>----- Text sent by Erik-Jan Bos follows ------- > This message is to inform you that SURFnet will stop announcing > 192.87.108.0/22 somewhere this week. Instead we will be announcing the > following four CIDR blocks: > - 192.87.0.0/16 (256 Cs, of which 192.87.108/22 is part) > - 145.0.0.0/9 (128 Bs) > - 145.128.0.0/10 (64 Bs) > - 145.192.0.0/11 (32 Bs) > > Soon we will stop announcing some (and later on: all) of the explicit > routes inside the four mentioned CIDR blocks. It depends on several > external factors who quick we will proceed. But the fact that SWITCH will > talk BGP4 real soon now, is very important for this! Erik-Jan, Thanks to SURFnet for this good news. I know from Thomas that SWITCH has similar plans. Would it be possible to know what are the plans of DFN, JANET, RENATER, GARR and other major service providers ? Any date ? Hope to ear from them very soon. We are close to 20,000 routes in Europe now :-) Time is now to use CIDR in production! -- Jean-Michel

2 1

Re: A couple of possibly interesting stats.
by Vadim Antonov 26 Mar '94

26 Mar '94

You don't need a CIDR-capable IGP to have a CIDR-capable network. iBGP-4 + *any* IGP will do the trick. It's a good idea for regionals to start register aggregate NACRs, though. --vadim

2 1

Re: A couple of possibly interesting stats.
by Vince Fuller 26 Mar '94

26 Mar '94

A lot of the regional networks have more than one attachment point to ANSnet. Some use one as primary and one as backup. Most of the regional networks announce some of their networks as primary at one attachment point and other networks at another attachment point. This means that that regional could not aggregate before reaching ANSnet because to do so would mean losing the load balancing. One longer term way around this is to have ANS accept more specific routes plus an aggregate and propogate the more specific routes into it's IBGP but not propogate them further (just the aggregate). Is this really a common case? BARRNet has two attachments to ANS/NSFNET, but they are strictly primary/secondary, so the same aggregates will be advertised at both locations. Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before. --Vince

6 6

Re: A couple of possibly interesting stats.
by solensky＠ftp.com 25 Mar '94

25 Mar '94

> Seriously - Let's take this discussion of how to make the estimates > more accurate off line or move it to the ALE list (there is one > right?)... Yup: the subscribe address is "ipv4-ale-request(a)ftp.com" Try "ipv4-ale-request(a)research.ftp.com" if you get a bounce message on the former. I'll forward your message over there. > (Hey - it's only memory on the > routers - we'll just plug in 64MB were we need it:). The thought struck me the other day: according to Moore's law, memory performace doubles every two years. If the size of the net tables continue to double every year,.. -- Frank

1 0

Re: A couple of possibly interesting stats.
by solensky＠ftp.com 25 Mar '94

25 Mar '94

> I'm not saying CIDR isn't going to be highly beneficial, it will be. > I'm just saying that Tony's figures are optimistic. This brings up one of the items I wanted to talk about in ALE next week: the figures that I've been generating for the growth charts to estimate how much CIDR helps are also based off Merit's nets.unl files, but look at only the first AS number to decide where the aggregation occurs.. Would that be considered overly pessimistic? -- Frank

4 3

A couple of possibly interesting stats.
by Tony Bates 25 Mar '94

25 Mar '94

Seeing as CIDRD is around the corner and there's been the usual questions on how many CIDR routes, "more specific"s, etc. I did a couple of stats based on a full routing table (actually taken from an Ebone router) from last night at 21:00 UTC. The first table focuses on the current classful routes being passed around by AS and the amount of gain CIDR would give *IF* we could aggregate as the AS level. It shows the number of nets per AS so we see who is announcing what in terms of BGP as well as what the number of CIDR nets would be advertised if we could aggregate at this level (I know we cant but does give an indication as is the best you can base things on without local information - one day when the routing registry is fully integrated with an aggregate registry this should of course be possible - well that's the theory at least). One thing also to note in the this list is there are FOUR unknown ASes or at least I cant look them up. If you are the proud owner of one of these please register them a.s.a.p. The second shows the actual "*real live*" CIDR routes in the production Internet plus showing where "more specific" routes exist and where not. It also shows who is originating these aggregates and what the number of "more specific"s are also being announced (if any). In some case where the possible (all based on classful possible at the moment) "more specific"s equals the actual "more specific"s this means actually generating more routes than in the old classful world (but I know you all know this). The interesting point here are some SPs are really going for it i.e. no "more specific" routes whatsoever. Or, they're not real production nets of course. Hope this gives you an idea of what ASes are doing what. See you in Seattle. --Tony. Table 1 +++++++ ASnum NetsNow NetsCIDR % Gain Description AS701 1177 545 53.7% ALTERNET-AS AS174 1142 786 31.2% NYSERNET-AS AS372 908 693 23.7% NSN-AMES-AS AS1717 731 499 31.7% RENATER AS19 606 475 21.6% CSS-DOMAIN AS786 574 274 52.3% The JANET IP Service AS560 546 407 25.5% NEARNET-EXT-AS AS1225 499 314 37.1% CICNET3-AS AS200 498 364 26.9% BARRNET-AS AS2551 493 241 51.1% NETCOM-AS AS1275 489 258 47.2% DFN-IP AS209 455 346 24.0% WESTNET-EAST AS1239 435 240 44.8% SprintLink AS600 417 220 47.2% OARNET-AS AS1740 417 299 28.3% CERFNET AS279 409 305 25.4% SURANET-AS-2 AS1270 370 189 48.9% EUnet/DE AS86 351 311 11.4% SURANET-AS AS114 341 281 17.6% SESQUINET-AS AS97 284 199 29.9% JVNC-AS AS1849 279 168 39.8% PIPEX, Public IP EXchange AS685 253 172 32.0% NWNET-AS AS204 241 194 19.5% PSCNET-AS AS517 232 121 47.8% XLINK-UKA AS271 206 93 54.9% BCNET-AS AS81 186 95 48.9% CONCERT AS137 185 118 36.2% GARR AS93 183 140 23.5% MIDNET-AS AS210 179 138 22.9% WESTNET-WEST AS601 167 146 12.6% CANET1-AS AS568 159 142 10.7% SUMNET-AS AS1290 159 102 35.8% EUNet GB AS297 154 124 19.5% NSN-UMD-AS AS2150 152 72 52.6% CSUNET-SW AS1250 150 74 50.7% SINGAPORE-AS AS2907 142 90 36.6% SINET-AS AS237 136 104 23.5% NSFNETTEST14-AS AS1899 126 106 15.9% Fnet, EUnet-France AS1257 126 99 21.4% SWIPnet Swedish IP Network AS1103 113 88 22.1% SURFnet IP AS813 109 77 29.4% CANET-ASN AS1887 103 48 53.4% NASK Polish Research and Academic Comput AS1836 102 73 28.4% EUnet/CH Autonomous System AS267 101 85 15.8% CICNET2-AS AS555 89 52 41.6% MSCNET-AS AS2018 84 67 20.2% UNINET-ZA AS559 83 59 28.9% SWITCH, Swiss Academic and Research Netw AS719 79 52 34.2% LANLINK autonomous system AS1902 79 53 32.9% CESNET backbone A - EBONE AS378 77 50 35.1% ILAN AS766 76 55 27.6% RedIRIS Autonomous System AS22 76 57 25.0% NOSC AS1329 75 27 64.0% NSFNETTEST34-AS AS1901 73 52 28.8% EUnet Austria AS1955 72 34 52.8% Computer and Automation Institute AS2116 69 38 44.9% EUnet Norway AS1237 69 34 50.7% EUNSOL-AS AS2118 68 45 33.8% RIPE-ASNBLOCK2 AS2044 68 36 47.1% WORLDNET-AS AS109 68 43 36.8% CISCOSYSTEMS AS1267 63 48 23.8% I2U Autonomous System AS591 62 44 29.0% NSTN-AS AS376 62 36 41.9% RISQ-AS AS2548 62 41 33.9% DIGEX-AS AS293 61 53 13.1% ESNET-WEST-AS AS1890 60 38 36.7% NLnet Autonomous System AS2572 55 41 25.5% MORENET AS1204 55 34 38.2% SUNYNET-ASN-AS AS224 54 37 31.5% UNINETT, The Norwegian University & Rese AS2109 53 31 41.5% DKnet, EUnet Denmark AS1930 53 46 13.2% RCCN-NET AS2497 51 40 21.6% JNIC-ASN AS2110 51 23 54.9% IEunet (EUnet/Ireland) backbone AS AS1323 48 39 18.8% NSFNETTEST28-AS AS1251 48 41 14.6% ANBR-AS AS1741 46 38 17.4% FUNET autonomous system AS790 45 33 26.7% EUnet Finland AS2493 45 27 40.0% FONOROLA-EAST AS2119 45 30 33.3% TelePost IP net AS760 44 36 18.2% University of Vienna, Austria AS1241 44 24 45.5% FORTHnet Greek IP Service Provider AS542 39 30 23.1% ARNET AS1759 37 26 29.7% The DataNet IP Service AS1332 37 34 8.1% NSFNETTEST37-AS AS1982 35 29 17.1% ASN-NWNEXUS AS1729 34 33 2.9% TIPnet - Unidata IP services AS1331 34 23 32.4% NSFNETTEST36-AS AS2380 32 17 46.9% ESTNET Autonomous System AS789 31 25 19.4% IN2P3 AS2915 30 26 13.3% SPIN-NET AS2048 30 29 3.3% LANET-1 AS1850 30 28 6.7% ISnet Autonomous system AS2917 26 10 61.5% oleANe, Groupe APYSOFT AS2895 26 14 46.2% FREEnet AS2529 26 17 34.6% Demon Internet Ltd AS1328 26 24 7.7% NSFNETTEST33-AS AS1213 26 23 11.5% HEAnet autonomous system AS1967 25 16 36.0% TR-NET AS1324 25 23 8.0% NSFNETTEST29-AS AS803 24 23 4.2% SASK-NET-AS AS544 24 21 12.5% The DataNet IP Service AS2107 24 17 29.2% The ARNES IP Service AS2277 23 20 13.0% ECUANET AS1312 23 20 13.0% VA-TECH-AS AS2836 21 19 9.5% SUNET-STHLM AS2568 21 12 42.9% CTSNET AS2386 21 15 28.6% INS-AS AS771 20 20 0.0% NSN-RICE-AS AS684 20 17 15.0% MBNET-AS AS3130 20 9 55.0% RAIN-ASN AS2611 20 13 35.0% AS for BELNET sites connected to Brussel AS2111 20 18 10.0% AS for BELNET sites connected to Leuven AS1654 20 10 50.0% NORDUnet Iceland, Poland and Baltic AS2819 19 12 36.8% EUnet Czechia AS AS2702 19 12 36.8% INTERSERVE AS1705 19 12 36.8% GM-INDY-NET AS2828 18 10 44.4% INTERNEX AS278 18 15 16.7% RAM-AS AS2125 18 13 27.8% EUNET-WIN AS1327 18 18 0.0% NSFNETTEST32-AS AS286 17 12 29.4% EUnet-central AS AS2765 17 13 23.5% CONNECTED AS184 17 17 0.0% NSFNETTEST4-AS AS1752 17 13 23.5% BT main internal data network AS2902 16 12 25.0% WN-WY AS2637 16 13 18.8% GEORGIA-TECH AS2134 16 11 31.2% EUnet-SPAIN AS AS2120 16 7 56.2% DAXnet AS2043 16 13 18.8% European Multiprotocol Backbone AS1112 16 7 56.2% Montanuniversitaet Leoben, Austria AS35 15 13 13.3% MICATON AS2772 15 10 33.3% HKIGS AS1662 15 11 26.7% ANS-BLK1 AS1333 15 12 20.0% NSFNETTEST38-AS AS1205 15 7 53.3% Johannes Kepler University AS513 14 13 7.1% CERN/HEPNET AS2012 14 13 7.1% UNINET1 AS195 14 6 57.1% SDSC-AS AS1326 14 11 21.4% NSFNETTEST31-AS AS1274 14 10 28.6% GMD AS800 13 11 15.4% NLNET-AS AS2607 13 10 23.1% Slovak technical university AS2602 13 11 15.4% RESTENA AS2905 12 9 25.0% TICSA-ASN AS175 12 12 0.0% AFWL-AS AS68 11 11 0.0% LANL-INET-AS AS3380 11 6 45.5% PPPL-AS1 AS2704 11 9 18.2% HOOKUP-NET-A AS266 11 11 0.0% CICNET1-AS AS1227 11 11 0.0% SDSC-TEST1-AS AS683 10 10 0.0% ARGONNE-AS AS3463 10 10 0.0% ACES-AS AS2552 10 10 0.0% WUSTL-ASN AS1922 10 9 10.0% UAKOM-DAMIS AS714 9 7 22.2% APPLE-ENGINEERING-AS AS679 9 8 11.1% Technical University Vienna LAN AS3365 9 7 22.2% MCSNET AS2699 9 8 11.1% BBN-DSI1 AS2631 9 4 55.6% DISCOVERY-AS AS2136 9 7 22.2% PCC-TECHNO-AS AS1755 9 7 22.2% EBONE AS AS164 9 8 11.1% DDN-MB-AS AS1321 9 8 11.1% NSFNETTEST26-AS AS3403 8 8 0.0% TIAC AS233 8 7 12.5% NSFNETTEST10-AS AS1330 8 8 0.0% NSFNETTEST35-AS AS1294 8 7 12.5% PS-NETPLEX-AS AS698 7 6 14.3% ASN-UIUC-REGION-AS AS577 7 6 14.3% CA-NET-AS AS3404 7 7 0.0% COLORADOCOOP AS2847 7 6 14.3% LITNET, Lithuanian Academic and Research AS2108 7 7 0.0% Croatioan Academic and Research Network AS17 7 6 14.3% PURDUE-CS AS1322 7 7 0.0% NSFNETTEST27-AS AS3113 6 4 33.3% DOC-ESA-ASN AS2933 6 6 0.0% REALTIME AS2856 6 3 50.0% BT-UK-AS AS1853 6 4 33.3% ACOnet Backbone AS1842 6 6 0.0% USGS-AS AS1835 6 5 16.7% DENet - Danish Network for Research and AS1262 6 6 0.0% NSN-NCAR-AS-AS AS1104 6 6 0.0% NIKHEF-H AS73 5 5 0.0% WASHINGTON-AS AS3428 5 5 0.0% ESNET-AS AS3407 5 4 20.0% INTERPATH-NC AS3133 5 4 20.0% DHHS-NET-ASN AS292 5 5 0.0% ESNET-CENTRAL-AS AS2848 5 3 40.0% MSU.SU Autonomous system AS2715 5 5 0.0% REDERIO-AS AS2609 5 4 20.0% ASNBLK-RIPE AS26 5 5 0.0% CORNELL AS2276 5 5 0.0% OCS-AS1 AS194 5 4 20.0% USAN-AS AS1880 5 4 20.0% Stupi, house man's policy AS1803 5 2 60.0% ICMNET-5 AS1238 5 4 20.0% ICM-MALAYSIA AS1206 5 5 0.0% PSCNET-HS-AS AS1115 5 2 60.0% Austrian Academy of Sciences AS377 4 4 0.0% SNLA-NET-AS AS3111 4 4 0.0% DIRECT AS2927 4 3 25.0% ZONE-NET1 AS2900 4 4 0.0% WN-AZ AS2845 4 4 0.0% SUNET-LUND AS2841 4 4 0.0% SUNET-CTH AS2840 4 4 0.0% SUNET-GBG AS2832 4 4 0.0% SUNET-UMEA AS2820 4 4 0.0% Zelenograd Networks Community AS2605 4 4 0.0% CESNET backbone B - EMPB AS2578 4 4 0.0% RELCOM-DEMOS AS2555 4 4 0.0% INTER-GRP-B AS2146 4 4 0.0% CRNET AS2131 4 3 25.0% Goedel School Ges.m.b.H. AS1888 4 4 0.0% CWI-Amsterdam AS AS1784 4 4 0.0% SPRINTLINK AS1273 4 4 0.0% ECRC-RBS AS1234 4 3 25.0% IVOWAN-AS AS558 3 3 0.0% OLIVETTI-AS1 AS46 3 3 0.0% RUTGERS AS38 3 3 0.0% UIUC AS3381 3 3 0.0% MHPCC-AS AS3358 3 3 0.0% UCIA-AS AS3142 3 3 0.0% DORSAI AS3110 3 2 33.3% HOLONET AS3058 3 3 0.0% EMNET AS3 3 3 0.0% MIT-GATEWAYS AS2861 3 3 0.0% SNI-ZFE-AS AS2834 3 3 0.0% SUNET-UPPSALA AS2709 3 2 33.3% AOS-AS AS2706 3 3 0.0% HKSUPER AS2604 3 2 33.3% HS fuer Musik und darstellende Kunst, Gr AS1889 3 3 0.0% Hewlett-Packard Limited, AS1808 3 3 0.0% ICMNET-10 AS1800 3 3 0.0% ICM-Atlantic AS1776 3 2 33.3% ASN-WU-WIEN AS1747 3 3 0.0% IBMWATSON-AS AS1653 3 3 0.0% SUNET Swedish University Network AS1325 3 3 0.0% NSFNETTEST30-AS AS1292 3 3 0.0% ITESM-AS AS690 2 2 0.0% NSFNET-T3-RT-AS AS45 2 2 0.0% LLL-TIS-AS AS3447 2 2 0.0% CENTEL-CMDS AS3405 2 1 50.0% QNSNET AS3386 2 2 0.0% USNET-AS AS3134 2 2 0.0% USAID-ASN AS3127 2 2 0.0% CAPRICA-AS AS2843 2 2 0.0% SUNET-LINKOPING AS2831 2 2 0.0% SUNET-LULEA AS2643 2 2 0.0% IHEP-SU AS AS2599 2 1 50.0% SOVAM Teleport AS2561 2 2 0.0% Egyptian Networks AS2546 2 2 0.0% Ariadne Network (NCSR Demokritos) AS2047 2 2 0.0% KFKI-RMKI Autonomous system AS2038 2 2 0.0% IT-HEP Italian Hepnet AS2020 2 2 0.0% HWWILSON-AS AS2002 2 2 0.0% IBM-PV-AS AS1999 2 2 0.0% HOUSE-AS-1 AS1972 2 2 0.0% HPC-NET AS1782 2 2 0.0% UNKNOWN AS1754 2 2 0.0% DESY-HAMBURG AS1732 2 2 0.0% MIKROK-AS AS1660 2 2 0.0% ANS-BLK1 AS1133 2 1 50.0% DANTE/CERN T1 AS1125 2 2 0.0% SURFnet Test ASN AS9009 1 1 0.0% UNKNOWN AS9003 1 1 0.0% UNKNOWN AS9001 1 1 0.0% UNKNOWN AS8 1 1 0.0% RICE-AS AS603 1 1 0.0% CANET AS602 1 1 0.0% CANET2 AS565 1 1 0.0% VTTNET-AS AS549 1 1 0.0% ONET-AS AS545 1 1 0.0% NRI AS543 1 1 0.0% CONVEX AS3462 1 1 0.0% HINET-AS AS3461 1 1 0.0% GONZAGA-ASN AS3459 1 1 0.0% ONRAMP AS3425 1 1 0.0% ESNET-AS AS3397 1 1 0.0% EMI-AS AS3394 1 1 0.0% ELPRESS-AS AS3364 1 1 0.0% CSDCO-AS AS33 1 1 0.0% DEC-WRL-AS AS3152 1 1 0.0% FERMILAB AS3150 1 1 0.0% CLARKNET AS3139 1 1 0.0% ASEE AS3132 1 1 0.0% RCP-AS AS3114 1 1 0.0% DOJ-CRT-ASN AS2882 1 1 0.0% COREN-ONE AS288 1 1 0.0% ESA-AS AS2822 1 1 0.0% INNET BVBA AS2766 1 1 0.0% GLASNET AS2718 1 1 0.0% APSCN-AR AS2714 1 1 0.0% GSA_GOV AS2707 1 1 0.0% WEC AS2649 1 1 0.0% NAS2-AS AS2614 1 1 0.0% PUB AS2603 1 1 0.0% NORDUnet 2Mb AS2592 1 1 0.0% Turkish Universities and Research Center AS2588 1 1 0.0% Institute of Mathematics and CS AS2549 1 1 0.0% REDUDG AS2538 1 1 0.0% IBM-KINGS-AS AS2532 1 1 0.0% LOC AS2494 1 1 0.0% AKHNET Autonomous System AS2383 1 1 0.0% OTA AS238 1 1 0.0% NSFNETTEST15-AS AS2274 1 1 0.0% CBO AS2149 1 1 0.0% PSINET-2 AS2140 1 1 0.0% ISSC-AS AS2139 1 1 0.0% DOW1-AS AS2138 1 1 0.0% DOW2-AS AS2135 1 1 0.0% EuroKom Mail Service AS2128 1 1 0.0% DIT AS2112 1 1 0.0% RIPE-ASNBLOCK2 AS2049 1 1 0.0% AVL-GRAZ AS2036 1 1 0.0% JOANNEUM RESEARCH AS2028 1 1 0.0% BNR Europe AS2019 1 1 0.0% MORGAN-AS AS2004 1 1 0.0% TNO-HDO AS2003 1 1 0.0% EPRI-PA AS1997 1 1 0.0% IBMDES-AS AS1975 1 1 0.0% UMI-AS AS1957 1 1 0.0% ANSCIX-AS AS1956 1 1 0.0% IBMEVS-AS AS1934 1 1 0.0% ANS-RESTON-AS AS1882 1 1 0.0% Stupi, house woman's policy AS1804 1 1 0.0% ICMNET-6 AS1757 1 1 0.0% MDCI-AS AS1751 1 1 0.0% LEXMARK-AS AS1739 1 1 0.0% TAMNET AS1679 1 1 0.0% ANS-BLK1 AS1678 1 1 0.0% ANS-BLK1 AS1671 1 1 0.0% ANS-BLK1 AS1240 1 1 0.0% ICM-Pacific AS1224 1 1 0.0% NCSA-AS AS1134 1 1 0.0% PTT-Res Test AS1128 1 1 0.0% EuropaNET PoP Amsterdam AS1123 1 1 0.0% Technikum Vorarlberg AS1117 1 1 0.0% Universitaet fuer Bodenkultur, Wien AS1114 1 1 0.0% Graz University, Austria AS1113 1 1 0.0% Technische Universitaet Graz, AT AS1111 1 1 0.0% University of Klagenfurt, Austria AS1110 1 1 0.0% University of Innsbruck, Austria AS1109 1 1 0.0% AS Universitaet Salzburg Total 19400 13068 32.6% Table 2 +++++++ Explaination of Table 2 ------------------------ SR : Is there a "more specific" route advertised with the aggregate (Yes or No). P : Number of possible classful routes in aggregate. N : Actual "more specific" classful routes advertised. If P=N then actually advertising more routes rather than less. SR Aggregate Originator Start-Classful End-Classful P N -------------------------------------------------------------------------- Y 129.240.0.0/15 AS224 129.240 129.241 2 1 Y 130.232.0.0/15 AS1741 130.232 130.233 2 2 Y 192.36.2.0/23 AS1257 192.36.2 192.36.3 2 1 Y 192.36.18.0/23 AS1257 192.36.18 192.36.19 2 2 Y 192.36.220.0/23 AS1257 192.36.220 192.36.221 2 2 Y 192.71.152.0/23 AS1257 192.71.152 192.71.153 2 2 Y 192.87.108.0/22 AS1103 192.87.108 192.87.111 4 2 Y 192.87.136.0/22 AS1125 192.87.136 192.87.139 4 1 Y 192.91.242.0/23 AS513 192.91.242 192.91.243 2 2 N 192.108.196.0/23 AS1880 192.108.196 192.108.197 2 0 Y 192.108.200.0/21 AS1880 192.108.200 192.108.207 8 4 N 192.108.212.0/23 AS1880 192.108.212 192.108.213 2 0 N 192.121.64.0/23 AS1729 192.121.64 192.121.65 2 0 N 192.121.86.0/23 AS2836 192.121.86 192.121.87 2 0 Y 192.121.204.0/22 AS1257 192.121.204 192.121.207 4 4 Y 192.121.208.0/21 AS1257 192.121.208 192.121.215 8 8 Y 192.121.216.0/23 AS1257 192.121.216 192.121.217 2 2 Y 192.122.216.0/23 AS2110 192.122.216 192.122.217 2 2 Y 192.122.220.0/22 AS2110 192.122.220 192.122.223 4 4 N 192.150.56.0/21 AS1729 192.150.56 192.150.63 8 0 Y 192.150.64.0/20 AS1729 192.150.64 192.150.79 16 2 Y 192.150.80.0/21 AS1729 192.150.80 192.150.87 8 1 Y 192.216.0.0/16 AS200 192.216.0 192.216.255 256 115 Y 192.244.176.0/20 AS2497 192.244.176 192.244.191 16 8 Y 192.250.24.0/22 AS1890 192.250.24 192.250.27 4 4 Y 193.4.0.0/16 AS1850 193.4.0 193.4.255 256 29 N 193.10.6.0/23 AS2836 193.10.6 193.10.7 2 0 Y 193.12.54.0/23 AS1257 193.12.54 193.12.55 2 2 Y 193.12.56.0/23 AS1257 193.12.56 193.12.57 2 2 Y 193.12.94.0/23 AS1257 193.12.94 193.12.95 2 2 Y 193.12.106.0/23 AS1257 193.12.106 193.12.107 2 2 Y 193.12.118.0/23 AS1257 193.12.118 193.12.119 2 2 Y 193.12.122.0/23 AS1257 193.12.122 193.12.123 2 2 Y 193.12.128.0/22 AS1257 193.12.128 193.12.131 4 4 Y 193.12.150.0/23 AS1257 193.12.150 193.12.151 2 2 Y 193.44.0.0/16 AS1729 193.44.0 193.44.255 256 1 N 193.44.24.0/22 AS2836 193.44.24 193.44.27 4 0 Y 193.67.128.0/22 AS1890 193.67.128 193.67.131 4 4 Y 193.71.32.0/21 AS2116 193.71.32 193.71.39 8 7 Y 193.71.104.0/21 AS2116 193.71.104 193.71.111 8 8 Y 193.71.160.0/21 AS2116 193.71.160 193.71.167 8 8 Y 193.72.0.0/16 AS1836 193.72.0 193.72.255 256 56 Y 193.78.32.0/21 AS1890 193.78.32 193.78.39 8 8 Y 193.78.72.0/22 AS1890 193.78.72 193.78.75 4 3 Y 193.78.104.0/22 AS1890 193.78.104 193.78.107 4 4 Y 193.78.120.0/21 AS1890 193.78.120 193.78.127 8 6 Y 193.78.120.0/23 AS1890 193.78.120 193.78.121 2 2 Y 193.80.224.0/22 AS1901 193.80.224 193.80.227 4 2 Y 193.85.0.0/21 AS2819 193.85.0 193.85.7 8 4 Y 193.85.8.0/23 AS2819 193.85.8 193.85.9 2 2 Y 193.85.80.0/23 AS2819 193.85.80 193.85.81 2 2 Y 193.85.104.0/21 AS2819 193.85.104 193.85.111 8 3 Y 193.85.112.0/20 AS2819 193.85.112 193.85.127 16 4 Y 193.85.128.0/20 AS2819 193.85.128 193.85.143 16 2 Y 193.120.16.0/20 AS2110 193.120.16 193.120.31 16 16 Y 193.120.32.0/21 AS2110 193.120.32 193.120.39 8 8 Y 193.120.208.0/22 AS2110 193.120.208 193.120.211 4 2 Y 193.120.212.0/22 AS2110 193.120.212 193.120.215 4 2 Y 193.120.216.0/23 AS2110 193.120.216 193.120.217 2 2 Y 193.120.232.0/21 AS2110 193.120.232 193.120.239 8 1 Y 193.120.240.0/21 AS2110 193.120.240 193.120.247 8 2 N 193.128.40.0/21 AS1849 193.128.40 193.128.47 8 0 N 193.157.64.0/19 AS224 193.157.64 193.157.95 32 0 Y 193.166.0.0/16 AS1741 193.166.0 193.166.255 256 28 Y 193.170.54.0/23 AS1853 193.170.54 193.170.55 2 2 N 193.172.2.0/23 AS2043 193.172.2 193.172.3 2 0 Y 193.212.2.0/23 AS1257 193.212.2 193.212.3 2 2 Y 193.242.80.0/21 AS286 193.242.80 193.242.87 8 4 N 194.12.128.0/21 AS513 194.12.128 194.12.135 8 0 Y 198.30.0.0/16 AS600 198.30.0 198.30.255 256 165 Y 198.31.0.0/16 AS200 198.31.0 198.31.255 256 51 N 198.63.0.0/16 AS114 198.63.0 198.63.255 256 0 N 198.66.0.0/17 AS114 198.66.0 198.66.127 128 0 N 198.84.4.0/22 AS701 198.84.4 198.84.7 4 0 Y 198.92.0.0/17 AS109 198.92.0 198.92.127 128 46 N 198.93.160.0/19 AS109 198.93.160 198.93.191 32 0 Y 198.213.0.0/16 AS114 198.213.0 198.213.255 256 17 N 198.214.0.0/15 AS114 198.214.0 198.215.255 256 0 Y 198.216.0.0/16 AS114 198.216.0 198.216.255 256 4 Y 199.0.0.0/16 AS1239 199.0.0 199.0.255 256 64 N 199.0.192.0/20 AS1239 199.0.192 199.0.207 16 0 Y 199.1.0.0/16 AS1239 199.1.0 199.1.255 256 13 Y 199.2.0.0/16 AS1239 199.2.0 199.2.255 256 51 Y 199.3.0.0/16 AS1239 199.3.0 199.3.255 256 26 Y 199.18.0.0/16 AS600 199.18.0 199.18.255 256 65 N 199.108.0.0/16 AS1740 199.108.0 199.108.255 256 0 Y 202.24.208.0/20 AS2497 202.24.208 202.24.223 16 1 Y 202.32.0.0/16 AS2497 202.32.0 202.32.255 256 12

2 3

List of NSFNET configured aggregates
by Dale S. Johnson 25 Mar '94

25 Mar '94

FYI, the following command will now list the aggregates that are configured for AS690: >merit.edu% whois -h prdb.merit.edu listaggs >Prefix/Len NetName DATE AUP Metric:AS list >========== ======= ======== === ============== > >129.240/15 UIONET 94/03/11 N 1:1800 2:1879 3:1133 4:1240 >130.232/15 TURBO 94/03/25 N 1:1800 2:1879 3:1133 4:1240 >171.64/15 BARRNET-BBLOCK 94/03/25 N 1:200 2:201 >192.87.108/22 SIPLAN-AGGREGATE 94/03/22 N 1:1800 2:1133 3:1674 4:1240 >192.87.140/23 OPCW-AGGREGATE 94/03/25 N 1:1800 2:1133 3:1674 4:1240 >192.121.86/23 LIBRIS-EDS 94/03/11 N 1:1800 2:1879 3:1133 4:1240 >192.204.248/22 PREPNET-C 94/03/01 N 1:574 >192.212/16 NETBLK-SCE 94/03/25 N 1:1740 ... --Dale

1 0

Reachability of a host in CIDR-The Netherlands
by Erik-Jan Bos 22 Mar '94

22 Mar '94

BGPD, here are some results, FYI, regarding the reachibility of my laptoy living in a CIDR-block of which the individual C net is not explicitly announced. The results below are a snapshot of this weekend and yesterday. Some pattern is visible. If you want to test the reachability of ejpc5.wind.surfnet.nl, please do so, I leave it on until 5:30 pm local time (4:30 pm UTC, or 11:30 am EST). --- Start of table NET ASN REGIONAL COUNTRY RESULT ------------ -------- -------------------- ------------- --------- 133.11.0.0 AS 372 NSN-AMES-AS JP Unreach 128.250.0.0 AS 372 NSN-AMES-AS AU Unreach 130.217.0.0 AS 372 NSN-AMES-AS NZ Unreach 128.171.0.0 AS 372 NSN-AMES-AS Hawaii, US Unreach 192.12.192.0 AS 137 GARR IT Reach (%) 130.59.0.0 AS 559 SWITCH CH Reach (*) 158.152.0.0 AS2529 Demon Internet Ltd UK Reach (&) 193.63.94.0 AS 786 JANET IP UK Reach (&) 193.1.193.0 AS1213 HEAnet IE Reach (#) 193.124.134.0 AS2683 RADIO-MSU Network RU Reach (^) 192.36.125.0 AS1653 SUNET SE Reach 130.43.0.0 AS 714 APPLE-ENGINEERING-AS US Reach 192.87.45.0 AS1104 NIKHEF-H NL Reach 147.32.1.0 AS2605 CESNET backbone B CZ Reach 130.206.0.0 AS 766 RedIRIS ES Reach (*) Path from mentioned network to laptoy is through Washington2.Dante.net and icm-dc-1-E0.icp.net. (%) Path from mentioned network to laptoy is through ESnet and NSFnet (San Francisco) and Washington2.Dante.net. (&) Path from mentioned network to laptoy is through ICM. (#) Path from mentioned network to laptoy is through Ebone (although a direct path through EMPB exists). (^) Between Hamburg and Amsterdam is a non-revealed path (all routers return "*" in the traceroute. --- End of table __ Erik-Jan.

5 6

Re: Reachability of a host in CIDR-The Netherlands
by Erik-Jan Bos 22 Mar '94

22 Mar '94

Jeff, > > These now should be reachable to you, 192.87.108/22 was included in > > the reconfiguration of ANS' network done this morning. Also, many fewer > > packets should end up at Washington2.Dante.net since the default has been > > eliminated. > > Thank you very much for the explanation. I'll sleep much better now > (whenever I get to sleep tonight :-( ). Networks MUST be configured in > the Merit/NSFnet PRDB before NSI will route to them. Thanks for this information. Sleep well :-). If you feel up to it, have a look at the following long traceroute output: survis bos % t -m 50 -g munnari.oz.au 192.87.111.59 traceroute to 192.87.111.59 (192.87.111.59), 50 hops max, 40 byte packets 1 Utrecht1.router.surfnet.nl (145.41.49.161) 5 ms 4 ms 4 ms 2 Amsterdam1.router.surfnet.nl (145.41.1.193) 9 ms 9 ms 8 ms 3 Amsterdam1.dante.net (192.87.4.35) 15 ms 10 ms 16 ms 4 194.41.0.18 (194.41.0.18) 591 ms 605 ms 622 ms 5 icm-dc-2-E1.icp.net (192.157.65.225) 576 ms 575 ms 579 ms 6 icm-fix-e-H0-T3.icp.net (192.157.65.122) 1095 ms 719 ms 586 ms 7 192.203.229.246 (192.203.229.246) 579 ms 576 ms 583 ms 8 t3-1.Washington-DC-cnss58.t3.ans.net (140.222.58.2) 590 ms 640 ms 615 ms 9 mf-0.Washington-DC-cnss56.t3.ans.net (140.222.56.222) 588 ms 580 ms 652 ms 10 t3-0.New-York-cnss32.t3.ans.net (140.222.32.1) 591 ms 587 ms 588 ms 11 t3-1.Cleveland-cnss40.t3.ans.net (140.222.40.2) 657 ms t3-0.New-York-cnss32.t3.ans.net (140.222.32.1) 588 ms 651 ms 12 t3-1.Cleveland-cnss40.t3.ans.net (140.222.40.2) 668 ms 597 ms 596 ms 13 t3-2.Chicago-cnss24.t3.ans.net (140.222.24.3) 604 ms 603 ms 609 ms 14 * mf-0.San-Francisco-cnss9.t3.ans.net (140.222.8.193) 795 ms 727 ms 15 t3-0.enss144.t3.ans.net (140.222.144.1) 860 ms 660 ms 652 ms 16 ARC5.NSN.NASA.GOV (192.203.230.12) 653 ms 661 ms 654 ms 17 usa.gw.au (132.160.240.2) 875 ms 832 ms 817 ms 18 national.gw.au (139.130.4.1) 836 ms * 1074 ms 19 rb2.rtr.unimelb.EDU.AU (192.43.209.7) 836 ms 1308 ms 914 ms 20 * itee.rtr.unimelb.EDU.AU (128.250.3.8) 832 ms 1107 ms 21 mulkirri.cs.mu.OZ.AU (128.250.29.2) 855 ms 833 ms 914 ms 22 munnari.OZ.AU (128.250.1.21) 841 ms 943 ms 826 ms 23 mulkirri.cs.mu.OZ.AU (128.250.1.1) 827 ms 856 ms 823 ms 24 itee.rtr.unimelb.EDU.AU (128.250.29.1) 846 ms * 916 ms 25 rb2.rtr.unimelb.EDU.AU (128.250.3.7) 827 ms 854 ms 853 ms 26 vic.GW.AU (192.43.209.1) 920 ms 827 ms 837 ms 27 usa.gw.au (139.130.4.5) 1005 ms 856 ms 842 ms 28 132.160.240.1 (132.160.240.1) 845 ms 842 ms 845 ms 29 * t3-0.enss144.t3.nsf.net (192.203.230.253) 880 ms 832 ms 30 t3-1.San-Francisco-cnss9.t3.ans.net (140.222.9.2) 825 ms 830 ms 866 ms 31 mf-0.San-Francisco-cnss8.t3.ans.net (140.222.8.222) 897 ms * 904 ms 32 t3-0.Chicago-cnss24.t3.ans.net (140.222.24.1) 841 ms * * 33 * t3-0.Cleveland-cnss40.t3.ans.net (140.222.40.1) 1028 ms 831 ms 34 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 832 ms 868 ms 832 ms 35 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 881 ms 836 ms 1189 ms 36 mf-0.Washington-DC-cnss58.t3.ans.net (140.222.56.194) 836 ms 832 ms 831 ms 37 t3-0.enss145.t3.ans.net (140.222.145.1) 1088 ms 842 ms 832 ms 38 192.203.229.245 (192.203.229.245) 953 ms 963 ms 841 ms 39 icm-dc-2-H0-T3.icp.net (192.157.65.121) 839 ms 831 ms * 40 icm-dante-E0.icp.net (192.157.65.226) 833 ms 916 ms 873 ms 41 194.41.0.17 (194.41.0.17) 830 ms 829 ms 978 ms 42 Amsterdam2.router.surfnet.nl (192.87.4.24) 903 ms 990 ms 997 ms 43 Amsterdam1.router.surfnet.nl (145.41.9.129) 839 ms 838 ms * 44 Utrecht1.router.surfnet.nl (145.41.1.194) 842 ms 840 ms 857 ms 45 ejpc5.wind.surfnet.nl (192.87.111.59) 929 ms 1667 ms 1007 ms Ergo, ejpc5 (in 192.87.111.0) is reachable from Australia. __ Erik-Jan.

1 0

Re: CIDR routes: Your input, please (fwd)
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Damir, > thank you for the explanation. I was affraid that networks 109 and 111 are > populated also. As far as they are empty I am not worried any more. Well, not for these two nets. But you should be worried. > > Your capability to reach 192.87.109.0 (not used at the moment) and > > 192.87.111.0 (in which my laptoy is living) is fully depending on your > > ability to interpret the CIDR routes received. > > We will probably load our cisco with a new version at the end of this week and > will be able to catch your CIDR route. That's good news. Since EMPB has proven to be BGP4 capable this means that you could be in good shape in the next weeks. > > As soon as CIDR is fully deployed SURFnet will remove the explicit > > announcements of 192.87.108.0 and 192.87.110.0 and only advertise > > 192.87.108.0/22. > > > > I read from your message that you are not able to ping (or prtraceroute) > > to my laptoy. Where are you defaulting to? > > Our default points to ESnet i.e. 3425 293, 3425 291. So I can reach your laptoy > but passing over US. Please send me the output of "prtraceroute ejpc5.wind.surfnet.nl". Thanks. __ Erik-Jan.

1 0

Re: CIDR routes: Your input, please (fwd)
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Damir, (Cc: to the Routing WG list, since this might be of interest to more people). > as far as I can see on GARR border router (AS137) now we are receiving > announcement for the two of four networks from block 192.87.108/22. Those > which are explicitly annonced. So, we can't ping your machine 192.87.111.59 > directly as there is no BGP entry for it neither for 192.87.109.0. > > GARR-gw.cnr.it#sh ip bgp 192.87.111.0 > % Network not in table > GARR-gw.cnr.it#sh ip bgp 192.87.109.0 > % Network not in table This is exactly where the fun part is. SURFnet is current announcing 192.87.108.0 and 192.87.110.0 as single class C networks. Furthermore, SURFnet is announcing 192.87.108.0/22 as a CIDR route. Whether or not, you are receiving CIDR routes (which means talking BGP4 in the first place) you should be able to reach 192.87.108.0 and 192.87.110.0, since they are announced explicitly. Your capability to reach 192.87.109.0 (not used at the moment) and 192.87.111.0 (in which my laptoy is living) is fully depending on your ability to interpret the CIDR routes received. As soon as CIDR is fully deployed SURFnet will remove the explicit announcements of 192.87.108.0 and 192.87.110.0 and only advertise 192.87.108.0/22. I read from your message that you are not able to ping (or prtraceroute) to my laptoy. Where are you defaulting to? __ Erik-Jan.

1 0

CIDR routes: Your input, please
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Routing WG, yesterday and this morning I sent some messages on the BGP4 Deployment list, which you might or might not have seen. I am resending parts to this dedicated list, to ask for your help, it will only cost you 2 minutes plus the sending of a mail message. Thanks for your cooperation. --- Start of first message SURFnet currently is announcing 192.87.108/22. Two out of the four Cs in this blocks are also explicitly annonced (192.87.108.0 and 192.87.110.0, these are production nets). I currently have a box (my personal laytoy) running in 192.87.111.0 and on the SURFnet backbone this network is routed. You can try to reach my box (192.87.111.59) doing pings or traceroutes (only), I leave it on tonight, but please be gentle to the laptoy :-). --- End of first message --- Start of second message Many people have been sending traceroutes to me (privately). Thanks for this! Up till now my laptoy has processed 5179 echo request, so you have been trying already. Thanks for any help. Y'all could help me by sending traceroutes to me (privately, I will summarize to the list). Please also fil out this small template when you send in the traceroute: Source Network: .................................... Source ASN : .................................... Country : .................................... --- End of second message Any input, privately, in much valued. __ Erik-Jan.

3 2

Re: CIDR routes: Your input, please
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Daniel, > > Erik-Jan Bos <erik-jan.bos(a)SURFnet.nl> writes: > > Source Network: .................................... > > Source ASN : .................................... > > Country : .................................... > > People on *this* list really should use "prtraceroute -v" instead > of filling in templates .... Absolutely! Please find below an example (only not to interesting): survis bos % prtraceroute -v ejpc5.wind.surfnet.nl traceroute with AS and policy additions [Mar 21 11:06:49 UTC] from AS1103 survis.surfnet.nl (192.87.108.3) to AS1103 ejpc5.wind.surfnet.nl (192.87.111.59) 1 AS1103 surrogate.surfnet.nl 192.87.108.1 [I] 2 AS1103 ejpc5.wind.surfnet.nl 192.87.111.59 [I] AS Path followed: 1103 AS1103 = SURFnet IP The laptoy was off line during the weekend, since I needed it for something else. It's back again. __ Erik-Jan.

1 0

Routing prefixes in the RIPE database?
by Havard Eidnes 11 Mar '94

11 Mar '94

Sorry to those of you who see this twice, I mis-spelt one of the addresses and want both groups to receive copies of any resulting discussion. - Havard ------------------------------ Message-Id: <9403092125.AA28955@ravn> To: routing-wg(a)ripe.net Cc: db-gw(a)ripe.net, hostmaster(a)sunet.se, hostmaster(a)uninett.no Subject: Routing prefixes in the RIPE database? Date: Wed, 09 Mar 1994 22:25:48 +0100 From: Havard Eidnes <Havard.Eidnes(a)runit.sintef.no> Hi, all. I've been thinking about what we should do wrt. routing prefixes that are not "natural" network numbers, ie. what should be done about CIDR routes. This was prompted by fear that the Merit people would get "confused" because the routing prefixes we send in NACRs for these days are not directly found in the RIPE database, but it would perhaps also make sense as seen from a general perspective to register routing prefixes (ie. CIDR routes) in the RIPE database. Point for discussion: 1) should we try to register routing prefixes as such in the RIPE database? I know some argue that should not be necessary, eg. with the counter- argument being "you can use 'show ip bgp <prefix>' and thereby inspect the 'aggregator' attribute to get a handle on where to direct trouble reports" etc. etc. However, this only works as long as the prefix is reachable, so... Also, how will this show up in the BGP routing table if it isn't really BGP routes which are aggregated, but the aggregate is "locally originated" in the AS in question? If I am correct in my guesses here, this all points in the direction of registering the prefixes administratively. If there is consensus that we should try to register routing prefixes in the database, I have the following proposals/suggestions: 2) the routing prefix should be a separate object from the "inetnum" object. The reasoning behind this is that "inetnum" is mostly used for registering assignments of natural network numbers -- the ranges registered are not always of power-of-2 size, so cannot be represented as a single routing prefix. I suggest "rout-pfx" as long-form name. 3) the format when registering a routing prefix could be <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the obvious in-between. 4) lookup of a "natural IP network number" with WHOIS in the RIPE database should give as result all the routing prefixes it is a part of, as well as the traditional "inetnum" output. Hint for implementation in the RIPE database: from a routing prefix eg. "129.240/15" create keys for all the natural IP network numbers covered by this prefix with pointers to the routing prefix object. This should be a fairly straight-forward approach (say I who haven't really hacked on the RIPE software... ;-) Side-effect: lookup of unassigned network numbers within a routing prefix after this change will no longer give the "No entries found for the selected source(s)" result when whois is used, but instead the routing prefix(es) will be returned, but no inetnum object. I haven't really thought much about what attributes the "rout-pfx" object should/could contain -- there probably shouldn't be all that many, and we can probably give a pointer for recursion via the AS where the aggregate is originated (and we all have our ASes registered, right? ;-). Comments? - Havard

5 5

Routing prefixes in the RIPE database?
by Havard Eidnes 09 Mar '94

09 Mar '94

Hi, all. I've been thinking about what we should do wrt. routing prefixes that are not "natural" network numbers, ie. what should be done about CIDR routes. This was prompted by fear that the Merit people would get "confused" because the routing prefixes we send in NACRs for these days are not directly found in the RIPE database, but it would perhaps also make sense as seen from a general perspective to register routing prefixes (ie. CIDR routes) in the RIPE database. Point for discussion: 1) should we try to register routing prefixes as such in the RIPE database? I know some argue that should not be necessary, eg. with the counter- argument being "you can use 'show ip bgp <prefix>' and thereby inspect the 'aggregator' attribute to get a handle on where to direct trouble reports" etc. etc. However, this only works as long as the prefix is reachable, so... Also, how will this show up in the BGP routing table if it isn't really BGP routes which are aggregated, but the aggregate is "locally originated" in the AS in question? If I am correct in my guesses here, this all points in the direction of registering the prefixes administratively. If there is consensus that we should try to register routing prefixes in the database, I have the following proposals/suggestions: 2) the routing prefix should be a separate object from the "inetnum" object. The reasoning behind this is that "inetnum" is mostly used for registering assignments of natural network numbers -- the ranges registered are not always of power-of-2 size, so cannot be represented as a single routing prefix. I suggest "rout-pfx" as long-form name. 3) the format when registering a routing prefix could be <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the obvious in-between. 4) lookup of a "natural IP network number" with WHOIS in the RIPE database should give as result all the routing prefixes it is a part of, as well as the traditional "inetnum" output. Hint for implementation in the RIPE database: from a routing prefix eg. "129.240/15" create keys for all the natural IP network numbers covered by this prefix with pointers to the routing prefix object. This should be a fairly straight-forward approach (say I who haven't really hacked on the RIPE software... ;-) Side-effect: lookup of unassigned network numbers within a routing prefix after this change will no longer give the "No entries found for the selected source(s)" result when whois is used, but instead the routing prefix(es) will be returned, but no inetnum object. I haven't really thought much about what attributes the "rout-pfx" object should/could contain -- there probably shouldn't be all that many, and we can probably give a pointer for recursion via the AS where the aggregate is originated (and we all have our ASes registered, right? ;-). Comments? - Havard

1 0