- routing-wg - mailman.ripe.net

Weekly Routing Table Report
by Routing Analysis 18 Oct '01

18 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 19 Oct, 2001 Analysis Summary ---------------- BGP routing table entries examined: 110006 Origin ASes present in the Internet Routing Table: 11920 Origin ASes announcing only one prefix: 4395 Transit ASes present in the Internet Routing Table: 1551 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: 61 Non-routable prefixes present in the Routing Table: 1 Prefixes being announced from the IANA Reserved Address blocks: 15 Number of addresses announced to Internet: 1298884804 Equivalent to 77 /8s, 107 /16s and 104 /24s Percentage of available address space announced: 35.0 Percentage of allocated address space announced: 66.9 Percentage of available address space allocated: 52.4 Total number of prefixes smaller than registry allocations: 74537 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16475 Prefixes being announced from the APNIC address blocks: 15087 APNIC Region origin ASes present in the Internet Routing Table: 1382 APNIC Region origin ASes announcing only one prefix: 461 APNIC Region transit ASes present in the Internet Routing Table: 229 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 82749745 Equivalent to 4 /8s, 238 /16s and 169 /24s Percentage of available APNIC address space announced: 69.8 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/7 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 75759 Prefixes being announced from the ARIN address blocks: 53844 ARIN Region origin ASes present in the Internet Routing Table: 7176 ARIN Region origin ASes announcing only one prefix: 2146 ARIN Region transit ASes present in the Internet Routing Table: 717 Average ARIN Region AS path length visible: 5.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 219103009 Equivalent to 13 /8s, 15 /16s and 63 /24s Percentage of available ARIN address space announced: 81.6 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: 17768 Prefixes being announced from the RIPE address blocks: 14148 RIPE Region origin ASes present in the Internet Routing Table: 3369 RIPE Region origin ASes announcing only one prefix: 1788 RIPE Region transit ASes present in the Internet Routing Table: 605 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 109171596 Equivalent to 6 /8s, 129 /16s and 211 /24s Percentage of available RIPE address space announced: 72.3 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 1577 1291 Telstra Pty Ltd 2764 410 358 connect.com.au pty ltd 703 373 336 UUNET Technologies, Inc. 2907 373 1880 SINET Japan 4755 290 164 Videsh Sanchar Nigam Ltd. Aut 7474 251 274 Optus Communications Pty Ltd 4134 242 1862 Data Communications Bureau 4766 185 1466 Korea Internet Exchange for " 4740 184 27 OzEmail ISP 7539 174 230 TANet2, sponsored by NSC, TAI 9443 160 54 Primus Telecommunications 2521 139 171 PSINet Japan 17557 132 8 Pakistan Telecom 9768 131 363 Korea Telecom 4786 122 14 NetConnect Communications Pty 4763 120 69 Telstra New Zealand 9583 119 61 Satyam Infoway Ltd., 4713 118 901 NTT Communications Corporatio 17561 114 167 Internet service provision to 7657 107 22 The Internet Group Limited RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 912 1948 UUNET Technologies, Inc. 3301 434 950 TeliaNet Sweden 1257 273 512 SWIPnet Swedish IP Network 680 241 2309 DFN-IP service G-WiN 3215 236 523 France Telecom / &Equant 5515 195 688 Sonera Finland Autonomous Sys 3320 190 1940 Deutsche Telekom AG 786 185 1890 The JANET IP Service 8708 163 17 Romania Data Systems S.A. 1103 144 4089 SURFnet BV 15870 141 10 Global Center Frankfurt 5400 139 64 Concert European Core Network 719 133 289 LANLINK autonomous system 2856 130 8968 BTnet UK Regional network 3303 130 560 Swisscom Ltd 1270 129 732 UUNET Germany 5549 129 83 Nextra Deutschland GmbH + Co. 15878 118 9 Global Center Paris 517 112 252 KPNQwest Germany GmbH 12302 109 7 MobiFon S.A. ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2282 9083 UUNET Technologies, Inc. 3908 1152 1638 Supernet, Inc. 7018 1074 7309 AT&T 1 859 8587 BBN Planet 7046 815 1021 UUNET Technologies, Inc. 1239 743 3389 Sprint 209 584 2238 Qwest 3967 581 471 Exodus Communication 690 498 75 Merit Network 2914 475 2267 Verio, Inc. 4293 454 112 Cable & Wireless USA 3561 434 2384 Cable & Wireless USA 2149 433 331 Performance Systems, Inc. 3549 378 843 Global Crossing 721 374 4389 DLA Systems Automation Center 705 365 60 UUNET Technologies, Inc. 577 351 636 Bell Advanced Communications 4323 351 358 Time Warner Communications, I 5106 351 242 Ameritech Advanced Data Servi 3741 345 773 The Internet Solution Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2282 9083 UUNET Technologies, Inc. 1221 1577 1291 Telstra Pty Ltd 3908 1152 1638 Supernet, Inc. 7018 1074 7309 AT&T 702 912 1948 UUNET Technologies, Inc. 1 859 8587 BBN Planet 7046 815 1021 UUNET Technologies, Inc. 1239 743 3389 Sprint 209 584 2238 Qwest 3967 581 471 Exodus Communication 690 498 75 Merit Network 2914 475 2267 Verio, Inc. 4293 454 112 Cable & Wireless USA 3301 434 950 TeliaNet Sweden 3561 434 2384 Cable & Wireless USA 2149 433 331 Performance Systems, Inc. 2764 410 358 connect.com.au pty ltd 3549 378 843 Global Crossing 721 374 4389 DLA Systems Automation Center 703 373 336 UUNET Technologies, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 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 22571 UNALLOCATED 64.214.53.0/24 3549 Global Crossing 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 22528 UNALLOCATED 192.25.225.0/24 701 UUNET Technologies, 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 5555 UNALLOCATED 192.156.8.0/24 721 DLA Systems Automati 5555 UNALLOCATED 192.156.41.0/24 721 DLA Systems Automati 5555 UNALLOCATED 199.10.190.0/24 721 DLA Systems Automati 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 22501 UNALLOCATED 200.16.194.0/24 4926 Telintar S.A. 22501 UNALLOCATED 200.16.249.0/24 4926 Telintar S.A. 22501 UNALLOCATED 200.41.203.0/24 4926 Telintar S.A. 22501 UNALLOCATED 200.41.248.0/24 4926 Telintar S.A. 22501 UNALLOCATED 200.63.186.0/24 4926 Telintar S.A. 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, 22528 UNALLOCATED 208.251.6.0/24 701 UUNET Technologies, 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.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.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.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 Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 0.0.0.0/7 2856 BTnet UK Regional network 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.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:1 /8:18 /9:5 /10:8 /11:12 /12:34 /13:89 /14:227 /15:394 /16:7120 /17:1311 /18:2416 /19:7038 /20:5958 /21:4815 /22:7139 /23:9153 /24:62734 /25:345 /26:323 /27:260 /28:251 /29:146 /30:166 /31:1 /32:42 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 701 1460 2282 UUNET Technologies, Inc. 1221 1433 1577 Telstra Pty Ltd 3908 883 1152 Supernet, Inc. 7046 639 815 UUNET Technologies, Inc. 702 621 912 UUNET Technologies, Inc. 7018 564 1074 AT&T 690 495 498 Merit Network 4293 440 454 Cable & Wireless USA 209 418 584 Qwest 1 412 859 BBN Planet 1239 405 743 Sprint 3967 403 581 Exodus Communication 2764 365 410 connect.com.au pty ltd 5106 331 351 Ameritech Advanced Data Servi 705 313 365 UUNET Technologies, Inc. 11686 309 342 Education Networks of America 703 308 373 UUNET Technologies, Inc. 2149 308 433 Performance Systems, Inc. 4151 301 343 USDA 11371 299 310 Rhythms NetConnections Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:422 13:10 15:1 17:5 20:1 24:806 25:1 26:1 32:74 38:14 43:3 44:2 52:1 53:2 57:15 61:106 62:165 63:1958 64:1270 65:828 66:498 67:2 80:72 128:51 129:107 130:20 131:47 132:40 133:2 134:123 135:13 136:102 137:93 138:195 139:52 140:178 141:58 142:58 143:39 144:147 145:40 146:226 147:130 148:189 149:90 150:40 151:202 152:406 153:51 154:19 155:83 156:95 157:112 158:74 159:70 160:46 161:61 162:70 163:148 164:123 165:100 166:208 167:157 168:122 169:40 170:288 171:2 192:5639 193:1988 194:2079 195:841 196:459 198:4144 199:3959 200:2445 201:1 202:2929 203:4552 204:3377 205:2220 206:2903 207:2634 208:3155 209:3095 210:575 211:134 212:876 213:516 214:9 215:16 216:3017 217:389 218:2 End of report

1 0

Draft minutes routing wg - RIPE 40
by Joao Luis Silva Damas 18 Oct '01

18 Oct '01

Dear all, please find attached the draft minutes of the routing wg session during the recent RIPE 40 meeeting in Prague. Many thanks to Matthew Williams, from the RIPE NCC, who quickly and thoroughly produced the notes. Best Regards, Joao Damas RIPE NCC

1 1

RE: Multihoming - Resilience or Independence
by Tony Barber 16 Oct '01

16 Oct '01

At 01:18 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: >like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of >single ISP would do the you much better. I wonder why virtually nobody >offers such a service? Because extending your IGP to customer sites is a bit silly, bloating your IGP and inducing a potential for misinformation from an external domain. You really don't want to do this. It may work well in small networks but certainly not in large players. Tony

3 2

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

15 Oct '01

> > > 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 ). > > I am not sure I am following you here. Are you saying that we should > re-adress customers so that we get larger blocks of PA space > to give to > mulithomed customers? > > I think that re-addressing is pretty hard to do in any larger scale, > although that would certanly help some other issues. > That's why filtering /20 only without re-aligning the holes in the block won't work. In the end /20 make the routing table looks pretty but they are black-holing lots of traffic. As we all agree that re-assign address is NOT practical at all thus just filtering /20 block is not a good solution. > another good start would be to start reclaiming space that > has been handed > out from various ISPs old B-space and later taken with the customer. I > know a few operators that have done that (including us to > some extent), > and it's a rather demanding task but will help the operators > and reudce > the routing table as well. > > - kurtis - > I am with you here. Starting from the beginning is much better than asking them to change later. 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 Tony Barber 15 Oct '01

15 Oct '01

At 07:09 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: > >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 ^^^^^^^^^^^^^^^^^^^^ And there is the first problem. Tony

1 0

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

15 Oct '01

> -----Original Message----- > From: Aled Morris [mailto:aledm@qix.co.uk] > Sent: Friday, October 12, 2001 8:59 AM > To: Stephane Bortzmeyer > Cc: Nipper, Arnold; Dave Pratt; lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Thu, 11 Oct 2001, Stephane Bortzmeyer wrote: > > >Or, said in an other way: RIPE policies make very difficult > to be multihomed, > >therefore people in RIPEland take a lot of time to explain > that multihoming is > >bad. > > RIPE doesn't make up the policies - the members make the policies. > > RIPE didn't invent IP either, nor did they have a say in the design of > router architecture, nor in the pricing of RAM chips. > > Multihoming which relies on long prefixes being carried in the default > free zone, and/or more AS numbers, simply doesn't scale. That isn't a > policy matter, it's simple math. > > Which policy do you think should be changed in order to "solve" the > multihoming problem? > > Aled > -- > QiX Limited > I do think it is policy related. For example, Customer Alpha want to be multi-homed from the very beginning so he requests a /24 block from RIPE. What RIPE should do is asking which TWO ISPs Alpha is going to use. Let's say the policy requires Alpha to be under the CIDR block between these two ISPs according to a table like: UUnet & CW : 123.45.32.0/20 UUnet & Quest : 123.45.64.0/20 Ebone & Sprint: 123.45.96.0/20 ... and IX range: 123.45.128.0/20 Some note about this example: 1. The major ISP can always filter these range at /20 without worring the holes inside them. 2. It won't need to cover 100% of multi-homed customer but if major ISPs are covered it will reduce the routing table dramatically. 3. For IX people(more than 2 ISPs), it won't be aggregate possible but by allocating them in the same range we might find some small blocks (/23 /22 are highly possible ) that are aggregate possible. This is just one example what RIPE CAN do. And because it involves different ISPs it certainly looks like a community affair that belongs to the RIR level. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

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

15 Oct '01

> > > 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. > > If I only have three addresses I need some form of NAT on my > home network, > and that will brak my services as well as block the > Web-server, just as > point out. So I need a routable block. > OK. There are two different requirements here. One is people just want to connect to Internet and have different links for back-up thus no-need for static IP. The problem will be the SOHO customers running application that needs static IP address. Assume they uses /28 then it will be a big problem for the up-stream to leak them into the global routing table. By just filtering out /28 won't solve the problem. But I think it is a little bit easier to make them to be reassigned to the aggregate block with their back-up link provider, don't you think ? This way, we can have the cake and eat it too. > > > > 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 ?) > > No, but in order to use this Sat uplink I need to have > globally routable > address block. Which will pollut the routigtable. So in my extream > example, we would end up with a address block per SOHO user. > > - kurtis - > My point is still you can have these customers' business and making sure they are ASSIGNED (by you) on the aggregate block so the other ISP can aggregate them. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Hallgren, Michael 15 Oct '01

15 Oct '01

> > > If it is a outage and you are running BGP you will need to > wait for your > router to converge. In worst case you will be dragged into the routing > problems. However, I agree with Randy that 90% of outages are due to > local-tail problems. > > I agree that two links to two operators are more reliable, > but the real > questions are if they are enough MORE reliable to justify the extra > routes, and if so how do we implement this? And this should > be a general > solution all the way down to the residential users... > OK. I went backstreams up the thread. Sure, since we're talking about "all the way down to the residential users..." > I am not conviced that having multiple upstreams for entrprises, SOHO, > residentials or even small ISPs are worth it. OK mh > > - kurtis - > >

1 0

RE: more specific routes in today reality
by Hallgren, Michael 15 Oct '01

15 Oct '01

> > > This however, does not mean though that multiple uplinks to > more than one > > provider gives you more security than mulitple uplinks to one. > > I completely disagree with you. > So do I (at least in this little part of the thread, which I haven't had the opportunity to follow at all length). For example, a provider-wide routing (or performance, or whatever) problem would be your problem if homed only to that one provider. > Multiple links may have failure modes in addition to and > identical to some > of the failure modes of a single connection, but multiple > links also removes > a complete calls of failure modes associated with a single connection. > > This is a pretty fundemental tenet of communications systems > in general as > is not limited to IP. > mh > Peter > >

3 3

Multihoming - Resilience or Independence
by Dave Pratt 15 Oct '01

15 Oct '01

Hiya All, There has recently been a long thread, getting rather technical, about how best to achieve multihoming with the best resilience, etc. However, I feel there is another perhaps stronger argument as to why a customer wishes to obtain, keep and announce his own prefix(es): Bandwidth costs are reducing rapidly and customers do not wish to be tied to a single provider because of the pain associated with renumbering their address space. Going through the hoops to achieve multihoming may not improve resilience but, especially if they are "slow" setting up the second connection, the bandwidth can be cheaper as the customer can change ISPs much more easily if the price stays too high. It would be interesting to know which fraction of the "unclean" address space is singly connected. Our customer base may be unusual, but over 50% would not suprise me. Cheers Dave ps. Do not let any customers see this email..... :-)

11 19