- routing-wg - mailman.ripe.net

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

more specific routes in today reality
by Vladimir A. Jakovenko 15 Oct '01

15 Oct '01

Hello. My apologies if mentioned below issues have already been discussed. If they were - pls just point me to the location where I can find more on that subject. According to my observations at least since this summer the RIPE NCC staff promotes usage of more specific PA routes (originated by more than one AS) for multihomed customers opposite to the "classic" scheme with PI addresses (or new enterpise LIR ;-). In this situation we are going to expect increase of ammount of: 1. Routes with more than one origin. 2. Less specific routes within existing more specific. Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) refer to rfc1930 which contains section 7 - "One prefix, one origin AS": Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ According to measurements on RIPE DB dump on Oct 4 there were about 17% of prefixes with more than on origin AS. It isn't just RIPE specific - measurements from other IRRs are close. Announcement of less specific routes within existent more specific route (lets assume that there is no bgp routing process misconfiguration - both, less and more specific, routes have route objects) clashes with an aggregation issues promoted in many RIPE documents. In 1990th such announces would be treated as typical "bad practice" but now they are more and more close to "regular practice". Just in fact there is still some network operators, whose routing policy (in the part of BGP peers filtering) had been formed by influence of rfc1930 and other aggregation issues, states something like that: "if peer announces more specific routes within existent less specific route, all more specific routes will be rejected unless peer explicity asks to accept it". Unfortunately it is difficult to dispute such policy unactuality without appropriate documents. Is it possible at least "to legalize" applicability of more specific routes with more than one origin for multihoming purposes in ripe-185 successor? On my opinnion it would be also good to: 1. Create new RIPE document which would describe usage of more specific routes with multiple origins for multihoming, including all pros and cons of such technique. 2. Extend ripe-127 successor with references to new document mentioned above or (why not?) integrate both of them in one document. 3. Extend ripe-211 successor with something like that: "Due to tendency of increasing number of small blocks (smaller than the default allocation size) of PI or PA (more specific multihoming, load balancing, etc) addresses network operators taking routing decisions based on prefix length are recommended to accept and route longer (up to /24) prefixes with valid route objects." -- Regards, Vladimir.

16 45

RE: Multihoming - Resilience or Independence
by van Eijk, Peter (NL - Diemen) 15 Oct '01

15 Oct '01

Hi, I have been following this discussion for a few days now, and it has struck me that there has been little discussion about the *monetary value* of large blocks and aggregations to participants. Such a discussion could lead to "charging the polluters" of the number space. E.g. it seems obvious that a PI block is more valuable than a PA block of the same size, an an unfragmented block is more valuable etc. Cost concious organisations could then be better motivated to clean up their act. A little research turned up a paper called: SUGGESTIONS FOR MARKET-BASED ALLOCATION OF IP ADDRESS BLOCKS. By Paul Resnick, 1995. Has anything ever resulted from that discussion? My personal/professional reason for being interested is not so much in the operations of registries and providers, although i was involved in that area at one time. I have clients running serious internal WANs (100+ sites, 10.000+ seats, multiple internal IT organisations), who face serious challenges in (re-)allocating number space internally, even on (or especially on?) private range blocks (e.g. 10/8). Any insights into guidelines might be carried over to network management policies internal to those organisations. Adrian's proposal reminded me of the insight that our current 32 bit IP addresses have already in effect been extended to something like 48 bits using NAT. 24 bits address an organisation, within which an additional 24 bits (in a 10.0.0.0/8 network) are used to address individual nodes. For your insights i express my gratitude. Flames>/dev/null Peter van Eijk, Deloitte & Touche Bakkenist, Network Strategy & Architecture, tel: +31 6 53515927, www.van-eyk.net/pve, pvaneijk(a)deloitte.nl, pve(a)van-eyk.net > -----Original Message----- > From: owner-routing-wg(a)ripe.net [mailto:owner-routing-wg@ripe.net]On > Behalf Of Adrian Bool > Sent: 12 October 2001 16:17 > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > > Hi All, > > On Wednesday 10 October 2001 11:52, Nipper, Arnold wrote: > > I still can't see why the idea of having own netblocks and AS for > > multi-homing customers breaks if one ISP is going south. > But of course > > there are other and more financial drawbacks with this approach. > > > > > > The new mantra is: go home and do your homework > > I agreed with Arnold, that networks should be able to > muli-home without the > feeling that they are breaking the Internet. > > Of course that is sadly the case today. So, as per Arnold's > suggestion, I > did some homework on an alternative solution, basically to > IPv6. This is > only the first thoughts, just to get the main points across. > Its is far from > complete! > > If you can spare the time, wander to, > > http://logic.org.uk/ip-1.0.txt > > and see what you think. > > Regards, > > aid > > > -- > Adrian Bool | http://noc.vianetworks.net/ > Director, Global Network | tel://+44.1925.484061/ > VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ > > This e-mail message and its attachments are subject to the disclaimer published at the following website of Deloitte & Touche : http://www.deloitte.nl/disclaimer <http://www.deloitte.nl/index.asp?Pageid=010109135051734>

1 0

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