- routing-wg - mailman.ripe.net

RE: more specific routes in today reality
by Lu, Ping 15 Oct '01

15 Oct '01

> > Well, this can ofcourse then be taken to the extreme. Let's > assume that I > am cost concious resdient with a sattelite down-link (yupp, > they exist), > and a DSL line and a Cable link. Should I not be allowed the same easy > choice of up-link as the corporate world? > > Let's then assume that I have my home on VoIP only so NAT is > out. Do I get > my own AS-number and PA space then? > You are using three different IP addresses that are dynamically (OK. If you insist statically) assigned to three different links. But how can I reach your web server ? This is different from the corporate world to have the same IP coming in from different links. > I think we all agree that the current routing model is broken and no > longer does what we would expect it to do. However, I think > Randy is right > in that this will take at least 5 years to redo though. Just look at > addressing / CIDR /IPv6. That has taken what, 8 years? At > least, and we > are not really near any deployment. A CIDR like solution of this is > simple. Filter. > Maybe you are willing to black-hole some /24 block like eBay ? > > In this situation the most popular solution for local > customer, who needs > > reliable and cheap IP uplink and high speed access to > regional Internet > > resources, is to build two channels to local ISPs (not so > reliable, but much > > more cheaper than even one external uplink) and to local IX. In this SOHO situation you don't need a seperate entry in the global routing table. Also the point is two links (phone line won't die the same time as the satellite, will they ?) > > IXes are a bad example as just beeing present won't do. You > need to get > peers as well. And if you are a company my guess is that most > providers > rather sell you bandwidth than peer. This is going backward to ask company to have full mesh among all the ISPs ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

RE: Multihoming - Resilience or Independence
by Lu, Ping 15 Oct '01

15 Oct '01

It is odd that I have to agree with you on "customer do need multiple links to different ISPs" but I hope it is not because CW carries other ISP's non-CIDRable prefixes to let you think "CW less" about us. The point is we will aggregate other ISP's prefixes if they are CIDR able. Most of the case are there are holes in the range so CIDR is out-of-question. While the other camp insist to filter out any routes more specific than /20. They are doing nothing to re-allocate their PA assigned to multi-homed customers so CW can CIDR them into /20. The funny thing is the solution are controlled by the other camp but they are all talk but no action. (Or trying to tell you multi-homed is a bad idea because they can't deal with the routing table ). Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Peter Galbavy [mailto:peter.galbavy@knowtion.net] > Sent: Thursday, October 11, 2001 4:17 AM > To: Kurt Erik Lindqvist KPNQwest; Nipper, Arnold > Cc: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > > > the basic issue is that multi-homing is *the demand*. And > it's not the > ISP > > > who has to evaluate whether it's the right one but the > *customer*. We > live > > > in a customer - driven world. Money makes the world go round, not > techies. > > > > Is that really what the customer want? Or do they actually > want resilience > > and redundancy? And for that there are other ways... > > I have been watching this thread for a while now, and I > finally cannot help > but stick my oar in. > > There are two very clearly defined camps here; one the > 'technical' camp that > says 'we have many ways of making it work' or 'this is the > only way it will > work' and the other camp is the 'commercial' saying either > 'the customer > does not trust just one ISP' or 'I don't care how it works, > but it must > work'. > > Now, to add just another opinion to the thread, which is > really not that > different to some other but may possibly offer something new; > > In my line of work I have set-up 4 LIRs in the past two years > for companies > that have had either had bad experiences with their ISPs > (usually more than > one serially) or some have had to do all 'reasonable' things > to ensure good, > reliable connectivity for either contractual or due-diligence reasons. > > Regardless of how good an ISP is *now*, there will come a > time when they are > sold, bought, merge or go bust that causes change. My > personal bugbear was > INS. Great in the early days, but within days of > Clueless&Witless buying > them, the whole thing started to come apart. This is not > isolated, and they > are not the only ones at all. > > Also, especially in Europe, ISPs tend to be reliant on 3rd > party local-loop > carriers, even when we are talking about data-centre / > co-location delivery > of services. In the UK, all ISPs exclude 3rd party links from > SLAs. Right. > Good one. > > Trying to solve the problem of people not trusting ISPs by > changing the > technology to ensure that people *must* trust one ISP (IPv6 > IMHO is just > such a technology) is not a very customer friendly attitude. > It does not > work and will not work. > > In every other line of business, it is quite normal to buy > your product or > service from two suppliers, telecoms and Internet are the only real > exceptions. You could also discount other utilities, but > there is an issue > of delivery there that precludes efficient and real > competition, so no more > there please. As the Internet becomes a true necessity for > business, supply > will more and more be selected like any other service, and the same > contingencies will be made. > > So, IMHO, please stop trying to 'solve' the problem by > pretending that you > or any other ISP is reliable, civil and economically viable > and stop trying > to 'solve' the problem by mandating technology solutions that > enforce this > goal. It will not work. > > Peter > > >

2 1

The Cidr Report
by CIDR Report 13 Oct '01

13 Oct '01

This is an auto-generated mail on Fri Oct 12 23:00:02 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 12Oct01 0) General Status Table History ------------- Date Prefixes 051001 104449 061001 104665 071001 104597 081001 104752 091001 104769 101001 104817 111001 105289 121001 104773 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 1.0.0.0 from AS7623 AS Summary ---------- Number of ASes in routing system: 11764 Number of ASes announcing only one prefix: 7013 (3982 cidr, 3031 classful) Largest number of cidr routes: 872 announced by AS701 Largest number of classful routes: 1406 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1232 947 285 23.1% Telstra Pty Ltd AS701 1406 1185 221 15.7% UUNET Technologies, Inc. AS4151 304 172 132 43.4% USDA AS16473 201 76 125 62.2% Bell South AS577 304 185 119 39.1% Bell Advanced Communications Inc. AS13999 132 16 116 87.9% Mega Cable S.A. de C.V. AS4293 380 271 109 28.7% Cable & Wireless USA AS6595 167 60 107 64.1% DoD Education Activity Network As AS7018 777 672 105 13.5% AT&T AS721 366 266 100 27.3% DLA Systems Automation Center AS705 262 162 100 38.2% UUNET Technologies, Inc. AS2048 216 116 100 46.3% State of Louisiana AS4755 199 122 77 38.7% Videsh Sanchar Nigam Ltd. Autonom AS11686 215 138 77 35.8% Education Networks of America AS1239 481 407 74 15.4% Sprint AS7046 331 261 70 21.1% UUNET Technologies, Inc. AS4200 142 74 68 47.9% Apex Global Information Services, AS3464 162 95 67 41.4% Alabama SuperComputer Network AS12302 100 34 66 66.0% MobiFon S.A. AS724 216 151 65 30.1% DLA Systems Automation Center AS6471 129 64 65 50.4% ENTEL CHILE S.A. AS17557 128 66 62 48.4% Pakistan Telecom AS19632 70 11 59 84.3% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 309 254 55 17.8% Qwest AS306 60 6 54 90.0% National Guard Bureau AS226 145 93 52 35.9% Los Nettos AS400 135 84 51 37.8% Headquarters Standard Systems Cen AS17561 111 60 51 45.9% Internet service provision to Wes AS1 529 478 51 9.6% BBN Planet 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: Multihoming - Resilience or Independence
by SchmitzJo＠aol.com 11 Oct '01

11 Oct '01

Dear Nurani, you wrote: > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. I fully support this statement. > A few BCPs or guideline documents would be useful to point these > requesters to. Could this be an initiative for the routing-wg? I had some general input on this in the past months. I am also aware that there are some very early drafts which had not been circulated widely. >From the extent of the discussion it is obvious that this topic is interesting in various ways ;-) I have no objections against discussing this in the Routing WG, even with the initial modest goal of collecting the individual points of view (which would form a suitable basis to further develop the ideas presented). Nonetheless, it is obvious that within the Routing WG the focus is on technical issues only. Anybody who is interested in summarizing and presenting his/hers ideas is welcome to do so. I can easily reserve some time for that in the next Routing WG session in January to give this a focus. Just step up... :-) Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 11 Oct '01

11 Oct '01

That is very common procedure. In doing that at least 2 entries will be in the global routing table. And that's exactly the intension of the customer so in case one path failed(thus withdrwan properly ) the other path will kick in. If the provider B lost both connections to the customer and provider A then it lost the FULL correct routing table then this is not the issue of filtering /20 anymore. If provider B configure their BGP sessions right then it should withdraw all the routes from provider A and the customer. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Thursday, October 11, 2001 2:12 PM > To: Lu, Ping; lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > The customer will of course use 2 ISP - as requested. He will > use addresses > coming from a single PA block advertised by two providers. Of > course you > need to ensure 100% up connection between border routers. If > connection > between border routers is down one of them has to stop > advertising PA block. > Otherwise you have problem with return traffic. Imagine > provider B lost > connection to both customer and provider A. If B is still > advertising common > block some ASes may decide to reach customer over B, but B > cannot reach > customer network... In order to deliver proposed service > providers A and B > have to be connected with redundant network, which is quite common. > > Vicious circle (sp) as I see it: > *Providers want small routing tables > *Customers 100% up service so they as for resilience > *Providers usually have single POP in area > *Customers go BGP creating problem for community (table grows) and > themselves (BGP expert costs) > > Solution: > Providers enter into cooperation so they can advertise > customer addresses > over 2 independent BGP speakers. This idea is not very different from > existing aggregation. Specific routing information is hidden > in a group of > ASes instead of single AS. Of course you need some > administrative effort > (e.g. consistent billing) but from technical point of view it seems > feasible. I may be wrong, it won't be for the first time ;-) > Regards, > Jacek > > > -----Original Message----- > From: Lu, Ping [mailto:PLu@cw.net] > Sent: Thursday, October 11, 2001 5:02 PM > To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > > > -----Original Message----- > > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > > Sent: Wednesday, October 10, 2001 1:10 PM > > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > > Subject: RE: Multihoming - Resilience or Independence > > > > > > Hi, > > It seems multihoming discussion is an example of vicious > > circle (sp): More > > specific routes result in larger routing table but we want > > those routes and > > small table... Let me suggest a blasphemy: CIDR being > > advertised from two > > ASes. They say it should be only one, but why? In my > opinion there is > > nothing wrong in advertising CIDR from two ASes as long as > > you can guarantee > > each border router advertises CIDR only if it can reach it. > > Imagine the > > following construction: > > AS-A--\ > > +(OSPF) --(CIDR) > > AS-B--/ > > > > That's the problem. When customer want to be muitl-homed you > can't tell them > to use which ISP ? If the original prefix are not in the CIDR > with the other > ISP > then the customer have to change all their IP address. If > they don't then > the second > ISP have to leak the original prefix into global routing table. > > The question is how do you convince your customer to change > all their IP > addresses to > have a second link without the risk of losing its business ? > > > > Each BGP speaker advertises CIDR if and only if it learned > > about it from > > OSPF. It can be done, if you don't know how I'll forward > you a working > > example. Each border router generates a default router and > > injects it into > > OSPF. From technical point of view I see no reasons why it > > should not work. > > What you need is: > > * An agreement between ISPs > > * Change in procedure making such a union of ASes an > > officially blessed > > solution so nobody would dare to hinder cooperation with filters. > > * Optionally you may need a separate CIDR, since both ASes > > have to advertise > > same prefix. You need it if each ISP wants to have private > > customers in > > addition to shared ones. > > > > The customer has "an independent connection to two ISPs" > > which is the quest > > item. I see more commercial than technical problems with such > > a solution. > > However my expertise is limited and somebody can point > > drawbacks I cannot > > see. Feel free to burn me on a stake, that's the right way of > > treating a > > blasphemy ;-) > > Regards, > > Jacek > > > > It is a good idea but not easy to implement under the > pressure of making > revenue. > > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu(a)cw.net >

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 11 Oct '01

11 Oct '01

Hi, The customer will of course use 2 ISP - as requested. He will use addresses coming from a single PA block advertised by two providers. Of course you need to ensure 100% up connection between border routers. If connection between border routers is down one of them has to stop advertising PA block. Otherwise you have problem with return traffic. Imagine provider B lost connection to both customer and provider A. If B is still advertising common block some ASes may decide to reach customer over B, but B cannot reach customer network... In order to deliver proposed service providers A and B have to be connected with redundant network, which is quite common. Vicious circle (sp) as I see it: *Providers want small routing tables *Customers 100% up service so they as for resilience *Providers usually have single POP in area *Customers go BGP creating problem for community (table grows) and themselves (BGP expert costs) Solution: Providers enter into cooperation so they can advertise customer addresses over 2 independent BGP speakers. This idea is not very different from existing aggregation. Specific routing information is hidden in a group of ASes instead of single AS. Of course you need some administrative effort (e.g. consistent billing) but from technical point of view it seems feasible. I may be wrong, it won't be for the first time ;-) Regards, Jacek -----Original Message----- From: Lu, Ping [mailto:PLu@cw.net] Sent: Thursday, October 11, 2001 5:02 PM To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg(a)ripe.net; routing-wg(a)ripe.net Subject: RE: Multihoming - Resilience or Independence > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > It seems multihoming discussion is an example of vicious > circle (sp): More > specific routes result in larger routing table but we want > those routes and > small table... Let me suggest a blasphemy: CIDR being > advertised from two > ASes. They say it should be only one, but why? In my opinion there is > nothing wrong in advertising CIDR from two ASes as long as > you can guarantee > each border router advertises CIDR only if it can reach it. > Imagine the > following construction: > AS-A--\ > +(OSPF) --(CIDR) > AS-B--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > Each BGP speaker advertises CIDR if and only if it learned > about it from > OSPF. It can be done, if you don't know how I'll forward you a working > example. Each border router generates a default router and > injects it into > OSPF. From technical point of view I see no reasons why it > should not work. > What you need is: > * An agreement between ISPs > * Change in procedure making such a union of ASes an > officially blessed > solution so nobody would dare to hinder cooperation with filters. > * Optionally you may need a separate CIDR, since both ASes > have to advertise > same prefix. You need it if each ISP wants to have private > customers in > addition to shared ones. > > The customer has "an independent connection to two ISPs" > which is the quest > item. I see more commercial than technical problems with such > a solution. > However my expertise is limited and somebody can point > drawbacks I cannot > see. Feel free to burn me on a stake, that's the right way of > treating a > blasphemy ;-) > Regards, > Jacek > It is a good idea but not easy to implement under the pressure of making revenue. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

Weekly Routing Table Report
by Routing Analysis 11 Oct '01

11 Oct '01

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 12 Oct, 2001 Analysis Summary ---------------- BGP routing table entries examined: 109453 Origin ASes present in the Internet Routing Table: 11858 Origin ASes announcing only one prefix: 4365 Transit ASes present in the Internet Routing Table: 1533 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 73 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 16 Number of addresses announced to Internet: 1259798670 Equivalent to 75 /8s, 23 /16s and 0 /24s Percentage of available address space announced: 34.0 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 51.9 Total number of prefixes smaller than registry allocations: 74165 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16425 Prefixes being announced from the APNIC address blocks: 14952 APNIC Region origin ASes present in the Internet Routing Table: 1380 APNIC Region origin ASes announcing only one prefix: 463 APNIC Region transit ASes present in the Internet Routing Table: 234 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 81541744 Equivalent to 4 /8s, 220 /16s and 58 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 75297 Prefixes being announced from the ARIN address blocks: 53590 ARIN Region origin ASes present in the Internet Routing Table: 7132 ARIN Region origin ASes announcing only one prefix: 2124 ARIN Region transit ASes present in the Internet Routing Table: 715 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 218175305 Equivalent to 13 /8s, 1 /16s and 23 /24s Percentage of available ARIN address space announced: 81.3 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479, 21504 - 22527 ARIN Address Blocks 24/8, 63/8, 64/6, 68/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 17729 Prefixes being announced from the RIPE address blocks: 14094 RIPE Region origin ASes present in the Internet Routing Table: 3356 RIPE Region origin ASes announcing only one prefix: 1778 RIPE Region transit ASes present in the Internet Routing Table: 585 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 108572476 Equivalent to 6 /8s, 120 /16s and 175 /24s Percentage of available RIPE address space announced: 71.9 RIPE AS Blocks 1877 - 1901, 2043, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv Description 1221 1592 1312 Telstra Pty Ltd 2764 414 358 connect.com.au pty ltd 703 378 335 UUNET Technologies, Inc. 2907 370 1847 SINET Japan 4755 299 163 Videsh Sanchar Nigam Ltd. Aut 7474 243 274 Optus Communications Pty Ltd 4134 239 1862 Data Communications Bureau 4766 186 1466 Korea Internet Exchange for " 4740 177 38 OzEmail ISP 9443 159 54 Primus Telecommunications 2521 140 171 PSINet Japan 9768 131 363 Korea Telecom 17557 129 8 Pakistan Telecom 4786 123 14 NetConnect Communications Pty 4763 122 69 Telstra New Zealand 7545 121 23 TPG Internet Pty Ltd 4713 117 885 NTT Communications Corporatio 9583 116 60 Satyam Infoway Ltd., 17561 116 167 Internet service provision to 7539 108 150 TANet2, sponsored by NSC, TAI RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 910 1952 UUNET Technologies, Inc. 3301 438 937 TeliaNet Sweden 1257 273 512 SWIPnet Swedish IP Network 680 241 2309 DFN-IP service G-WiN 3215 236 515 France Telecom / &Equant 5515 194 688 Sonera Finland Autonomous Sys 3320 189 1940 Deutsche Telekom AG 786 186 1890 The JANET IP Service 1103 161 4089 SURFnet BV 8708 161 17 Romania Data Systems S.A. 15870 142 10 Global Center Frankfurt 5400 139 64 Concert European Core Network 719 133 289 LANLINK autonomous system 3303 129 560 Swisscom Ltd 2856 128 776 BTnet UK Regional network 5549 127 67 Nextra Deutschland GmbH + Co. 1270 125 731 UUNET Germany 15878 122 9 Global Center Paris 517 112 252 KPNQwest Germany GmbH 3269 106 807 TELECOM ITALIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2306 9166 UUNET Technologies, Inc. 3908 1150 1563 Supernet, Inc. 7018 1060 7264 AT&T 1 871 8587 BBN Planet 7046 811 1021 UUNET Technologies, Inc. 1239 738 3517 Sprint 3967 618 471 Exodus Communication 209 574 2253 Qwest 690 504 80 Merit Network 2914 489 2256 Verio, Inc. 4293 459 112 Cable & Wireless USA 705 415 67 UUNET Technologies, Inc. 3561 401 2356 Cable & Wireless USA 721 392 4407 DLA Systems Automation Center 2149 383 328 Performance Systems, Inc. 3549 383 843 Global Crossing 2548 356 999 Business Internet, Inc. 577 351 636 Bell Advanced Communications 5106 350 213 Ameritech Advanced Data Servi 4323 345 355 Time Warner Communications, I Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2306 9166 UUNET Technologies, Inc. 1221 1592 1312 Telstra Pty Ltd 3908 1150 1563 Supernet, Inc. 7018 1060 7264 AT&T 702 910 1952 UUNET Technologies, Inc. 1 871 8587 BBN Planet 7046 811 1021 UUNET Technologies, Inc. 1239 738 3517 Sprint 3967 618 471 Exodus Communication 209 574 2253 Qwest 690 504 80 Merit Network 2914 489 2256 Verio, Inc. 4293 459 112 Cable & Wireless USA 3301 438 937 TeliaNet Sweden 705 415 67 UUNET Technologies, Inc. 2764 414 358 connect.com.au pty ltd 3561 401 2356 Cable & Wireless USA 721 392 4407 DLA Systems Automation Center 2149 383 328 Performance Systems, Inc. 3549 383 843 Global Crossing List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 22153 UNALLOCATED 63.167.108.0/24 1239 Sprint 6971 UNALLOCATED 64.42.0.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.0.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.16.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.42.32.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.40.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.48.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.56.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.60.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.64.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.72.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.80.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.104.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.108.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.112.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.87.64.0/19 2516 Kokusai Denshin Denw 22153 UNALLOCATED 65.161.192.0/24 1239 Sprint 22153 UNALLOCATED 65.165.127.0/24 1239 Sprint 65000 PRIVATE 138.163.4.0/24 665 Department of Navy 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 22153 UNALLOCATED 168.215.234.0/23 1239 Sprint 22153 UNALLOCATED 168.215.235.0/24 1239 Sprint 22153 UNALLOCATED 168.215.236.0/23 1239 Sprint 22153 UNALLOCATED 168.215.237.0/24 1239 Sprint 6971 UNALLOCATED 192.103.229.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.230.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.232.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.236.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.237.0/24 2516 Kokusai Denshin Denw 1877 UNALLOCATED 192.108.201.0/24 1880 Stupi, house man's p 5555 UNALLOCATED 192.156.8.0/24 721 DLA Systems Automati 5555 UNALLOCATED 192.156.41.0/24 721 DLA Systems Automati 22290 UNALLOCATED 198.140.161.0/24 2914 Verio, Inc. 22051 UNALLOCATED 198.172.125.0/24 2914 Verio, Inc. 5555 UNALLOCATED 199.10.190.0/24 721 DLA Systems Automati 22290 UNALLOCATED 199.217.152.0/24 2914 Verio, Inc. 22290 UNALLOCATED 199.217.187.0/24 2914 Verio, Inc. 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 22290 UNALLOCATED 205.159.194.0/24 2914 Verio, Inc. 6971 UNALLOCATED 206.58.248.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.252.0/23 2914 Verio, Inc. 6971 UNALLOCATED 206.58.254.0/23 2914 Verio, Inc. 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 22290 UNALLOCATED 207.150.139.0/24 2914 Verio, Inc. 22237 UNALLOCATED 208.253.66.0/24 701 UUNET Technologies, 22075 UNALLOCATED 209.39.134.0/24 2914 Verio, Inc. 65515 PRIVATE 212.110.142.0/24 5593 CRIS-AS 6971 UNALLOCATED 216.105.192.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.121.224.0/19 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.202.0/24 2914 Verio, Inc. 6971 UNALLOCATED 216.174.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.240.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.128.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.128.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.140.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.144.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.160.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.176.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.184.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.200.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.216.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.220.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.224.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.232.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.236.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.240.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.229.96.0/20 2516 Kokusai Denshin Denw Advertised Unregistered Addresses --------------------------------- Network Origin AS Description 39.0.0.0/8 4554 Exchange Point Blocks 128.65.0.0/16 3463 ACES Research Inc 132.0.0.0/10 568 DISO-UNRRA 134.137.0.0/16 400 Headquarters Standard Systems 135.0.0.0/13 10455 Lucent Technologies 137.0.0.0/13 568 DISO-UNRRA 138.94.0.0/16 1 BBN Planet 144.7.0.0/16 701 UUNET Technologies, Inc. 153.34.0.0/15 701 UUNET Technologies, Inc. 153.36.0.0/14 701 UUNET Technologies, Inc. 154.150.0.0/16 6494 IDCI 158.0.0.0/13 568 DISO-UNRRA 164.233.0.0/16 6020 DISA NETWORK SERVICES 164.235.0.0/16 6025 US DOD NIC Unregistered 201.11.128.0/24 2764 connect.com.au pty ltd 201.115.100.0/24 7018 AT&T Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:5 /10:8 /11:12 /12:33 /13:87 /14:227 /15:392 /16:7090 /17:1301 /18:2394 /19:7014 /20:5928 /21:4792 /22:7117 /23:9086 /24:62372 /25:323 /26:329 /27:261 /28:257 /29:155 /30:195 /31:1 /32:56 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 701 1474 2306 UUNET Technologies, Inc. 1221 1446 1592 Telstra Pty Ltd 3908 874 1150 Supernet, Inc. 7046 633 811 UUNET Technologies, Inc. 702 620 910 UUNET Technologies, Inc. 7018 555 1060 AT&T 690 501 504 Merit Network 4293 445 459 Cable & Wireless USA 3967 438 618 Exodus Communication 1 422 871 BBN Planet 209 409 574 Qwest 1239 399 738 Sprint 2764 368 414 connect.com.au pty ltd 705 364 415 UUNET Technologies, Inc. 5106 329 350 Ameritech Advanced Data Servi 703 313 378 UUNET Technologies, Inc. 4151 301 343 USDA 11371 299 310 Rhythms NetConnections 4323 286 345 Time Warner Communications, I 11686 283 316 Education Networks of America Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:417 13:10 15:1 17:5 20:1 24:779 25:1 26:1 32:74 38:14 43:2 44:2 52:1 53:2 57:15 61:113 62:159 63:1937 64:1289 65:833 66:479 67:32 80:66 128:52 129:112 130:20 131:47 132:40 133:2 134:121 135:13 136:91 137:93 138:154 139:49 140:149 141:192 142:56 143:39 144:151 145:37 146:225 147:130 148:189 149:86 150:38 151:178 152:387 153:51 154:19 155:83 156:95 157:112 158:72 159:70 160:47 161:61 162:70 163:144 164:118 165:99 166:204 167:155 168:130 169:39 170:287 171:2 192:5618 193:1974 194:2074 195:846 196:467 198:4102 199:3889 200:2405 201:2 202:2827 203:4574 204:3366 205:2217 206:2873 207:2611 208:3158 209:3108 210:578 211:135 212:863 213:529 214:9 215:13 216:2999 217:384 218:2 End of report

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 11 Oct '01

11 Oct '01

> -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > It seems multihoming discussion is an example of vicious > circle (sp): More > specific routes result in larger routing table but we want > those routes and > small table... Let me suggest a blasphemy: CIDR being > advertised from two > ASes. They say it should be only one, but why? In my opinion there is > nothing wrong in advertising CIDR from two ASes as long as > you can guarantee > each border router advertises CIDR only if it can reach it. > Imagine the > following construction: > AS-A--\ > +(OSPF) --(CIDR) > AS-B--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > Each BGP speaker advertises CIDR if and only if it learned > about it from > OSPF. It can be done, if you don't know how I'll forward you a working > example. Each border router generates a default router and > injects it into > OSPF. From technical point of view I see no reasons why it > should not work. > What you need is: > * An agreement between ISPs > * Change in procedure making such a union of ASes an > officially blessed > solution so nobody would dare to hinder cooperation with filters. > * Optionally you may need a separate CIDR, since both ASes > have to advertise > same prefix. You need it if each ISP wants to have private > customers in > addition to shared ones. > > The customer has "an independent connection to two ISPs" > which is the quest > item. I see more commercial than technical problems with such > a solution. > However my expertise is limited and somebody can point > drawbacks I cannot > see. Feel free to burn me on a stake, that's the right way of > treating a > blasphemy ;-) > Regards, > Jacek > It is a good idea but not easy to implement under the pressure of making revenue. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: Multihoming - Resilience or Independence
by Boyan Krosnov 11 Oct '01

11 Oct '01

> Your prefixes (let's say /24) has to be announced by two ISPs > so the packets > will come back to you. If ISP A's link failed then that /24 > with ISP A in > the > ASPATH will be withdrawn. And ISP B's /24 will become active. > So in the > global > routing table there will be TWO /24 with different ASPATH. > > If this /24 is in ISP A's PA space then it saves one but the > one from ISP > B's one > NEEDs to be in the global routing table. Either I didn't understand you right, or you were wrong. It does not save a route in the DFZ. Let's say the customer gets A/24 out of proider A's A/17 prefix. B has to announce A/24 to the internet along with it's current prefixes. A has to announce A/17 AND A/24 to the internet. If A advertises A/17 only all the traffic for A/24 will go through B (because of the longest match rule), and I think that's not what that customer wants. So Being multihomed to two ASs with NAT or two addreses on each host does not create an extra route in the DFZ. Being multihomed to a single AS does not create an extra route in the DFZ. Being multihomed to two ASs (It doesn't matter PA or PI, separate AS or anounced by the two ASs. Prefix out of PA, separate AS is generally recognised to be the better technical solution.) does create at least 1 extra prefix and 2 extra as-paths in the DFZ. These are the facts about growth of the DFZ routing table caused by multihoming as I see them. There are of course other reasons for the growth like providers advertising 14 separate /24s when they can agregate it to /20 because "We were trying to do some input channel load balacing and have left this anouncements for months because our administrator does not have the time to deal with this thing, he/she has more important work to do". Now it's time to think how we can make people prefer the first 2 possibilities over the third. We've had enough of technical discussion I think. Regards, Boyan Krosnov, CCNP Network Administrator Lirex Net phone: +359-2-91815

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, It seems multihoming discussion is an example of vicious circle (sp): More specific routes result in larger routing table but we want those routes and small table... Let me suggest a blasphemy: CIDR being advertised from two ASes. They say it should be only one, but why? In my opinion there is nothing wrong in advertising CIDR from two ASes as long as you can guarantee each border router advertises CIDR only if it can reach it. Imagine the following construction: AS-A--\ +(OSPF) --(CIDR) AS-B--/ Each BGP speaker advertises CIDR if and only if it learned about it from OSPF. It can be done, if you don't know how I'll forward you a working example. Each border router generates a default router and injects it into OSPF. From technical point of view I see no reasons why it should not work. What you need is: * An agreement between ISPs * Change in procedure making such a union of ASes an officially blessed solution so nobody would dare to hinder cooperation with filters. * Optionally you may need a separate CIDR, since both ASes have to advertise same prefix. You need it if each ISP wants to have private customers in addition to shared ones. The customer has "an independent connection to two ISPs" which is the quest item. I see more commercial than technical problems with such a solution. However my expertise is limited and somebody can point drawbacks I cannot see. Feel free to burn me on a stake, that's the right way of treating a blasphemy ;-) Regards, Jacek

1 0