- routing-wg - mailman.ripe.net

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

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

10 Oct '01

Comments followed. > > Hi, > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > Some providers are multihomed > > but cannot cover the costs, even for a small lir. > > If you want to be multihomed, the costs for routers & co. are > far higher > than for being LIR. If you can't afford being LIR, be single-homed. > Great! Now we have to collect routing policies from thousands of small LIRs while still have to deal with thousands of small prefixes. > > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. > > To show the first few things from 192/8: > > *>i192.0.32.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > *>i192.0.34.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > * i192.0.36.0 195.206.66.61 3 100 0 > 3300 701 2914 20144 > i > *>i 195.158.244.133 100 0 > 1755 1239 2914 2014 > 4 i > * i192.1.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > * i192.2.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > > so if I filter those, why should the traffic go to XLink? > Why should > *any* traffic go to RIPE? It will be just blackholed (or > default-routed > to one of my upstreams, if I happen to have a default-route). > > Please do your homework about routing and BGP before selling people > consulting about multihoming. > 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. 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). 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 ) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 3

Reminder: RIPE-181 to RPSL Migration; Phase 3.
by Andrei Robachevsky 09 Oct '01

09 Oct '01

Dear Colleagues, [Apologies for multiple messages] On and from Monday, 15th October, 2001, the RIPE Database will no longer accept updates in RIPE-181 format. Mail robot at <auto-181(a)ripe.net> will be shutdown. The update path for the TEST database will also be changed. We plan to discontinue <test-181(a)ripe.net> service on 11th October, 2001. If you are still sending updates in RIPE-181 format, we advise you to switch to RPSL before 15th October. Please send your objects in RPSL format to <auto-dbm(a)ripe.net>. You may use ripe2rpsl utility to convert your RIPE-181 objects to RPSL format before sending them to the RIPE Database. The utility can be found at ftp://ftp.ripe.net/tools/ripe2rpsl-3.0.2.tar.gz. As part of this final step we will also make some cleanup of the ftp.ripe.net site. - The top directory for the RIPE Database software and flat object files is ftp://ftp.ripe.net/ripe/dbase. - "Short" versions of flat object files [*] will not be supported. [*]Version of a flat object file where attribute names are abbreviated to 2 letter code starting with '*'. The name of the object file also contains the object type in abbreviated form. For example ripe.db.in is the "short" version of the flat file for inetnum objects, while ripe.db.inetnum is the "long " version that is RPSL compliant. For more information please visit http://www.ripe.net/rpsl If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

RE: more specific routes in today reality
by Boyan Krosnov 09 Oct '01

09 Oct '01

Hi, There are other solutions for multihoming with NAT but I think we are again hitting that NAT against no NAT issue. I think that I should say it now to avoid further flamewars. NAT is not always a possible solution. It may be good to use it in some cases but it is not in others. Those other cases are the ones that this discussion is about. Or at least I think so :) CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Mirta Matic [mailto:mirta.matic@hinet.hr] > Sent: Tuesday, October 09, 2001 4:55 PM > To: Sascha E. Pollok > Cc: Gert Doering; Vladimir A. Jakovenko; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: more specific routes in today reality > > > Hello, > > have you ever heard for RADWARE solution for that problem? > Some RADWARE box can check distance to destination via both > ISP's and makes > decision from what IP address range have to get address for > NAT (of course, > customer have to have two ranges of addresses). If connection > via one ISP > failed, all traffic will be rerouted via another using IP > address from IP > address range of that ISP. > > Mirta Matic > mirta.matic(a)hinet.hr > > tel: +385 1 4914 207 > fax: +385 1 4914 222

1 0

The Cidr Report
by CIDR Report 06 Oct '01

06 Oct '01

This is an auto-generated mail on Fri Oct 5 23:00:01 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 05Oct01 0) General Status Table History ------------- Date Prefixes 280901 104483 290901 104988 300901 104943 011001 105036 021001 105301 031001 104637 041001 104254 051001 104449 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11739 Number of ASes announcing only one prefix: 6989 (3974 cidr, 3015 classful) Largest number of cidr routes: 844 announced by AS701 Largest number of classful routes: 1394 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1258 958 300 23.8% Telstra Pty Ltd AS4151 302 170 132 43.7% USDA AS16473 201 76 125 62.2% Bell South AS577 307 187 120 39.1% Bell Advanced Communications Inc. AS13999 131 20 111 84.7% Mega Cable S.A. de C.V. AS4293 375 267 108 28.8% Cable & Wireless USA AS2048 215 116 99 46.0% State of Louisiana AS4755 208 131 77 37.0% Videsh Sanchar Nigam Ltd. Autonom AS1239 481 410 71 14.8% Sprint AS3464 163 95 68 41.7% Alabama SuperComputer Network AS12302 98 32 66 67.3% MobiFon S.A. AS11686 192 126 66 34.4% Education Networks of America AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS4200 137 72 65 47.4% Apex Global Information Services, AS17557 124 65 59 47.6% Pakistan Telecom 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 AS3908 291 238 53 18.2% Supernet, Inc. AS400 137 85 52 38.0% Headquarters Standard Systems Cen AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 537 486 51 9.5% BBN Planet AS637 106 58 48 45.3% Department of Navy AS4323 246 198 48 19.5% Time Warner Communications, Inc. AS1913 152 104 48 31.6% Defense Logistics Agency AS10620 68 21 47 69.1% TVCABLE BOGOTA AS15290 246 200 46 18.7% AT&T Canada IES AS376 120 76 44 36.7% Reseau Interordinateurs Scientiqu AS5416 51 9 42 82.4% BATELCO-BH 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