- routing-wg - mailman.ripe.net

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

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

10 Oct '01

> -----Original Message----- > From: Steven Bakker [mailto:steven@icoe.att.com] > Sent: Wednesday, October 10, 2001 11:08 AM > To: Nipper, Arnold > Cc: Stephen Burley; Gert Doering; Dave Pratt; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > > Of course another prefix and another AS is added to the > routing table > > but thereby you are witdrawing at least more than two (both > prefs as well as > > AS). ==> table gets smaller. > > Your math is confusing... or maybe I'm misunderstanding the obvious. > Yes, multihoming adds another AS and (at least one) (longish) > prefix to > the routing table. But in your reasoning, which two prefixes > and one AS > are being withdrawn? If I resiliently multi-home to one ISP, > and I get > my address space from its block, I do not add any prefix or AS to the > (global) routing table. Even if I multi-home to two ISPs and > selectively NAT depending on the outgoing connection, I'll be NAT-ing > into the respective ISP's address space (which I presume is properly > aggregated), adding no prefix or AS. 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. The worse case: ISP A only announces aggregate block even if the link failed then the traffic will still go thru ISP A then get dropped. 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) 10 Oct '01

10 Oct '01

Hi, Decisions are based on both science and superstition. In my opinion requests to connect to "two independent ISPs" result mostly from superstition. BGP routing is not particularly good at servicing resilient links. If an access link to ISP fails it takes some time before routing reconfigures, we don't 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? From my perspective an entity running LIR is responsible for both IP addressing and IP traffic shaping. An entity may wish to become a LIR for number of business reasons. RIR should not verify validity of those reasons, however RIR should verify if to-be LIR understand what he applies for. This may mean technical consultancy for free, but since RIPE is a non-profit organization raised membership fees have to be spent anyway ;-) Regards, Jacek

1 0

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

10 Oct '01

> > >> > >> Great! Now we have to collect routing policies from > thousands of small LIRs > >> while still have to deal with thousands of small prefixes. > > > So? There is no difference between thousands of PI prefixes and > > "thousands of small LIRs", except that the latter actually have to > > *pay* for what they cause. > > Right. Strong ACK on this. > So what do the small LIRs solve ? > >> And if the major ISPs stop listening to the more specfic > routes then even > >> using the address from PI space won't work (unless you are > big enough). > > > Yes. This is what it's all about. Small PI space really > hurts people. > > Yep. And therefore these "small" PI stuff should be cleaned > up. The User itself > can use it internally and could get a /24 routed from PA space. > > But it is really not the optimum solution, as it waste's ip > address space. And > we have enough RFC1918 space... > This is not enough but I am going to go with this solution. Then we will ask you to assign only aggregatable address( to a /20 of course) to your customer if they are going to use CW as a backup ISP. You will happily reassign their addresses once they got a link from CW, right ? If you don't then what ? CW will have to leak your /24 to the world but it is you causing it. On the other hand, if our customer ask you to be the backup ISP, we will ask them to change all their DNS records, all their host tables, all their static IP configs to change to the new aggregatable block. If they think this is too much hassle, we will advice them not to use your service because you don't accept /24 multi-homed customer. This sounds realistic enough ? > > Letting "the whole world" see a /16 (from the upstream) and > the direct > > peers a /24 (or whatever) means global routing will just > work fine (over > > the upstream's PA block) and and IX routing will also work just fine > > (using the more specific). > > right, but is it generally used ? > I see a lot of /24 out of the same block from a /16 announced > space globally > (AS5511 for example) > > Because it is not the solution to the real world, that's why people can only talk about it but not really to enforce it. 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 10 Oct '01

10 Oct '01

> > > > Great! Now we have to collect routing policies from > thousands of small LIRs > > while still have to deal with thousands of small prefixes. > > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. To syncronize between the major RIRs is already dufficult enough, to make sure thousands of small LIRs all have correct info is not worth the problem it is trying to solve. > > > > Now more and more major ISPs are filtering out routes from > other ISPs ( > > becuase we don't have > > transit agreements) so the multi-homed customer have to > have their own AS. > > No. This is an interesting arguments, but the fact that C&W > has problems > with some of their peers doesn't mean "the whole world has to drown in > multihomed ASes". Get your contracts right. > Maybe you will carry other ISP's transit routes and they can dump about several GB of traffic for you to pass thru. And you are asking ISP to spend tons of money to carry the traffic that other ISPs are making money of ? Compared to this solution I think multihomed ASes is more acceptable. > > And if the major ISPs stop listening to the more specfic > routes then even > > using the address from PI space won't work (unless you are > big enough). > > Yes. This is what it's all about. Small PI space really > hurts people. > The thing is any ISP can decide to only accept /20 and above and claim any routes beyond those are not important. The truth is the INTERNET is bandwidth oriented and business like IX and webhosting are high bandwidth but not prefixes hungry. But they are hurting because someone think they are not wasting IP addresses enough. So the advice is if for any reason you need a backup link from different ISPs you better claim a /20 even a /24 is enough. > > All these solutions kind of imply that if you can't have > /20 prefix then you > > can't be multi-homed. What happen if a customer want to > have an OC-48 > > multi-homed link but only use prefix < /20 (that happens to > the Internet > > Exchange people a lot ) ? > > So announce it to the internet exchange. Why does it have to > be visible > in the whole world? > > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work > fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). > > Bad example. > So if a end-user uses one ISP's /24 from their PA space and he want to divide 50-50 traffic with a second ISP then what ? The second ISP will say no /24 allowed so can you ask the first ISP to assign a /20 ? (Don't worry CW will happily accept your /24) Even worse example. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0