more specific routes in today reality
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.
Hi, On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote:
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.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
2. Less specific routes within existing more specific.
Yes.
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":
Yes, but this is a non-issue here. [..]
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.
This is well possible, but not a necessity for this type of multihoming - to the contrary, in most cases it's a mistake or a transitional thing.
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.
Yes, but looking at the overall table, it's beneficial. - you have the same amount of routes as with "small PI", so it's not worse - if one is filtering "no /24's", the end site is *still* be reachable, which would not work with PI space. [..]
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?
RIPE has no power about *routing*. But there has been talk on the last meeting about writing a BCP concerning routing issues and recommendations (I have no idea what the state of this is or whether anybody is working on it). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, Vladimir,
In this situation we are going to expect increase of ammount of:
1. Routes with more than one origin.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
This looks like a little bit different idea of doing it (like Vladimir said): "- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)." This was suggested from a RIPE NCC Hostmaster when sending a PI-space req. This looks a little contrary to your opinion doesn't it? Sascha
Hi, On Tue, Oct 09, 2001 at 12:32:47PM +0200, Sascha E. Pollok wrote:
In this situation we are going to expect increase of ammount of:
1. Routes with more than one origin.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
This looks like a little bit different idea of doing it (like Vladimir said):
"- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course. Of course, even if it is not explicitely mentioned, the first provider will also have to let the more-specific "through" (otherwise only the second provider will get the traffic). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
"- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course.
We got this reply to a PI-space request for a customer that does not have his own ASN therefore ISPs would need to originate the route. Don't you think that this implies originating the prefix from two different ASes? (would appear when doing "sh ip bgp incons"). Sascha
"- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course. We got this reply to a PI-space request for a customer that does not have his own ASN
if the customer follows this path, they should get their own asn randy
Hi, On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote:
"- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course.
We got this reply to a PI-space request for a customer that does not have his own ASN therefore ISPs would need to originate the route. Don't you think that this implies originating the prefix from two different ASes? (would appear when doing "sh ip bgp incons").
Yes. But this would not be any different from getting a PI space and announcing it inconsistently, that is, originating it from both ISPs. Which is not a good practice in any case - I agree on that. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Oct 09, 2001 at 01:44:12PM +0200, Gert Doering wrote:
Hi,
On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote:
"- If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route (with the PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course.
We got this reply to a PI-space request for a customer that does not have his own ASN therefore ISPs would need to originate the route. Don't you think that this implies originating the prefix from two different ASes? (would appear when doing "sh ip bgp incons").
Yes. But this would not be any different from getting a PI space and announcing it inconsistently, that is, originating it from both ISPs.
Which is not a good practice in any case - I agree on that.
What is a good practice for small company who needs: 1. Small ammount of ip addresses (about /24) 2. Multihoming ? -- Regards, Vladimir.
On 2001-10-09T16:14:39, "Vladimir A. Jakovenko" <vovik@lucky.net> said:
What is a good practice for small company who needs:
1. Small ammount of ip addresses (about /24) 2. Multihoming
IMHO: Select a sensible provider with internal redundancy and multi home to that one via redudant links. -- "I'm extraordinarily patient provided I get my own way in the end." -- Margeret Thatcher
hi, On Tue, Oct 09, 2001 at 04:14:39PM +0300, Vladimir A. Jakovenko wrote:
Which is not a good practice in any case - I agree on that.
What is a good practice for small company who needs:
1. Small ammount of ip addresses (about /24) 2. Multihoming
The best practive is "to question the need for multihoming". Multihoming as a solution for *what*? Yes, there are good reasons for wanting to be multihomed, but things like "network stability" and "lower costs" are not the ones. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, Gert et al. On Tue, 9 Oct 2001, Gert Doering wrote:
hi,
On Tue, Oct 09, 2001 at 04:14:39PM +0300, Vladimir A. Jakovenko wrote:
Which is not a good practice in any case - I agree on that.
What is a good practice for small company who needs:
1. Small ammount of ip addresses (about /24) 2. Multihoming
The best practive is "to question the need for multihoming".
that ISP will be very happy to provide it... more cash... Viewing it from the angle of a *second* ISP which doesnt have a company as its client, probably they will be happy on getting a new client, independently if they are the main ISP of that client or not... its just a question of more money... If you have a client which is *only* connected to you and he asks you about multihoming, and you say its a bad ideia, you'll be probably seen as wanting to protect your revenue/business. If you go on talking about the global routing table (which is a correct aproach!), the client will not be that much interested, i guess... I mean, im on your side but i can recognize that this is a technical problem, an issue that clients want to see solved without getting even a clue on it.
Multihoming as a solution for *what*? Yes, there are good reasons for wanting to be multihomed, but things like "network stability" and "lower costs" are not the ones.
Especially lower costs... if people want redundancy on line availability they have to pay more for it... About stability, its not impossible, but keeping it simple with only one ISP will cause anybody a whole lot less of headaches.
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Regards, ps: Gert, when you get the next shipment of "no-/24's" badges, save me one, ok ? ;-) ./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
Hi,
On Tue, Oct 09, 2001 at 01:22:43PM +0200, Sascha E. Pollok wrote:
"- If PI is requested for multi-homing please explain why the
second
provider cannot route PA space as a more specific route (with
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@hinet.hr tel: +385 1 4914 207 fax: +385 1 4914 222 ----- Original Message ----- From: "Gert Doering" <gert@space.net> To: "Sascha E. Pollok" <sp@iphh.net> Cc: "Gert Doering" <gert@space.net>; "Vladimir A. Jakovenko" <vovik@lucky.net>; <lir-wg@ripe.net>; <routing-wg@ripe.net> Sent: Tuesday, October 09, 2001 1:44 PM Subject: Re: more specific routes in today reality the
PA block holder adding a more specific route too)."
This doesn't specify who is originating the BGP prefix. Both providers have to *route* it, of course.
We got this reply to a PI-space request for a customer that does not have his own ASN therefore ISPs would need to originate the route. Don't you think that this implies originating the prefix from two different ASes? (would appear when doing "sh ip bgp incons").
Yes. But this would not be any different from getting a PI space and announcing it inconsistently, that is, originating it from both ISPs.
Which is not a good practice in any case - I agree on that.
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Oct 09, 2001 at 12:15:57PM +0200, Gert Doering wrote:
Hi,
On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote:
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.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. In this situation more specific PA route can be originated by upstreams without allocation to customer new AS-num. Moreover, according to ripe-185: In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required.
2. Less specific routes within existing more specific.
Yes.
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":
Yes, but this is a non-issue here.
Why?
[..]
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.
This is well possible, but not a necessity for this type of multihoming - to the contrary, in most cases it's a mistake or a transitional thing.
I do not believe that the most of them are errors. Yes, not all of them was created for multihoming purposes (don't forget about incoming-channel load balancing :), but amount of multihoming part (on my opinnion) are increasing.
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.
Yes, but looking at the overall table, it's beneficial.
- you have the same amount of routes as with "small PI", so it's not worse
Agree.
- if one is filtering "no /24's", the end site is *still* be reachable, which would not work with PI space.
Disagree. During last time a number of routing curioses at least in our country have been caused by incorect announcements or filtering more specific routes within already announced less specific routes. If you want, I can describe some of the most common problems. PI addresses have its own set of problems, more specific PA addresses also have own set problems. This sets partly overlaps, but not same. And PA more specific isn't safer than PI. They just unsafe a bit more different.
[..]
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?
RIPE has no power about *routing*. But there has been talk on the last meeting about writing a BCP concerning routing issues and recommendations (I have no idea what the state of this is or whether anybody is working on it).
RIPE has the power to make recomendations and publish documents. RIPE NCC has the power in ip address space allocation. Good practice for people who make decisions in this region is to take into consideration RIPE recomendations. If RIPE NCC are going to propose usage of more specific routes for multihoming why not to cover that technique with all pros and cons in appropriate documents? -- Regards, Vladimir.
Hi, On Tue, Oct 09, 2001 at 04:02:08PM +0300, Vladimir A. Jakovenko wrote:
1. Routes with more than one origin.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. In this situation more specific PA route can be originated by upstreams without allocation to customer new AS-num. Moreover, according to ripe-185:
In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required.
I didn't realize this, but I agree with Randy on this: without their own AS number (and with them doing the BGP origination stuff and so on), this isn't going to work anyway - if they do not want to do BGP, then they should multi-home to the *same* ISP. [..]
- if one is filtering "no /24's", the end site is *still* be reachable, which would not work with PI space.
Disagree. During last time a number of routing curioses at least in our country have been caused by incorect announcements or filtering more specific routes within already announced less specific routes. If you want, I can describe some of the most common problems. PI addresses have its own set of problems, more specific PA addresses also have own set problems. This sets partly overlaps, but not same. And PA more specific isn't safer than PI. They just unsafe a bit more different.
They will be much safer when people start filtering out "long prefixes". Which will happen *soon*. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Oct 09, 2001 at 03:23:30PM +0200, Gert Doering wrote:
Hi,
On Tue, Oct 09, 2001 at 04:02:08PM +0300, Vladimir A. Jakovenko wrote:
1. Routes with more than one origin.
No - the more specifics are announced by the customer AS *only* (and the upstream AS that this blocks belongs to will permit them "through").
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. In this situation more specific PA route can be originated by upstreams without allocation to customer new AS-num. Moreover, according to ripe-185:
In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required.
I didn't realize this, but I agree with Randy on this: without their own AS number (and with them doing the BGP origination stuff and so on), this isn't going to work anyway - if they do not want to do BGP, then they should multi-home to the *same* ISP.
Sorry, but this _is_ working with multi-homing on different ISPs: 1. They can build eBGP interoperation with their uplinks using private AS numbers. Uplinks can strip down private AS numbers from AS-path on uplink's AS boundaries ( Router(config)#router bgp YYYY Router(config-router)#nei X.X.X.X ? remove-private-AS Remove private AS number from outbound updates ). 2. They can build any kind of IGP with uplink. Each uplink redistribute they more specific network from appropriate IGP protocol to BGP.
[..]
- if one is filtering "no /24's", the end site is *still* be reachable, which would not work with PI space.
Disagree. During last time a number of routing curioses at least in our country have been caused by incorect announcements or filtering more specific routes within already announced less specific routes. If you want, I can describe some of the most common problems. PI addresses have its own set of problems, more specific PA addresses also have own set problems. This sets partly overlaps, but not same. And PA more specific isn't safer than PI. They just unsafe a bit more different.
They will be much safer when people start filtering out "long prefixes".
People have been filtering out "longer prefixes" for years. And /24 been (informal) longest _acceptable_ prefix for long time (just look at CIDR reports history).
Which will happen *soon*.
One recomendation from one of our peers background: If you are going to filter prefixes based on prefix length _always_ filter it same on all sessions. Otherwise your chance to be affected by nasty routing loops will be very high. -- Regards, Vladimir.
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. ^ note the use of plural above. now read rfc 1930.
randy
On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote:
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. ^ note the use of plural above. now read rfc 1930.
Randy, rfc1930 consists of 563 lines. I suppose you are talking about: line 287: * Unique routing policy An AS is only needed when you have a routing policy which is different from that of your border gateway peers. Here routing policy refers to how the rest of the Internet makes routing decisions based on information from your AS. See "Sample Cases" below to see exactly when this criteria will apply. line 323: * Multi-homed site Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience. An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers. This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4. Also I think we should pay attention to rfc1930 header: line 10: Category: Best Current Practice line 11: March 1996 line 14: Guidelines for creation, selection, and registration of an Autonomous System (AS) Lets make some logick based on hypotetical situation with ISP (LIR) Network Engineer, Regional Internet Registry and the customer. ISP customer wants to be multihomed mostly for the following reason - resilience in the case of upstream failure (for my experience - on of the most common reasons). Yes, customer already tried to change: - ISP, - equipment, - technical staff. But hadn't reached enough resilience level. They technical and marketing staff considered that without multihoming they can't achieve sufficient resilience level. They don't ready to pay for Enterprise LIR because they know about PI. They asked ISP to help them to obtain PI block and AS num. With ISP Network Engineer assistance they filled in ripe-219. Network Engineer sent it to Regional Internet Registry. After some amount of time Regional Internet Registry staff replied to original request with something like: "They are aware that they can be multihomed with only PA space? Two or more LIRs can announce these address spaces if you discuss it with them, they don't even need an AS number. I don't quite understand why they feel the need to have PI space and all the problems that this will cause them. In addition if they ever have plans to expand in the future and need more address space they are going to have more trouble. I would suggest that you discuss this with them to see if they still want PI space. Finally, we are strict regarding the actual amounts of address space that customers request as there is a tendency to ask for more than is actually required, due to their agregation concerns." Lets imagine, that all customer uplinks are not against from such solution (there isn't any public IX-es, Telecom's, etc). After that please take a look at quoted lines from rfc1930. Who is reponsible for IP address space and AS-num allocation in LIR geographical region? RIR. If - RIR decided that multihomed customer (generaly) don't need separate AS-num - RIR routing database contains 17% of route objects with more than one origin (while rfc1930 defines it as exceptions) should Network Engineer think that: 1. Covered in rfc1930 "Best Practice" is a little bit outdated? 2. Meanings of "Multi-homed site", "Unique routing policy" and "resilenece" terms had been changed since 1996? 3. Something else? -- Regards, Vladimir.
But hadn't reached enough resilience level. They technical and marketing staff considered that without multihoming they can't achieve sufficient resilience level. They don't ready to pay for Enterprise LIR because they know about PI. They asked ISP to help them to obtain PI block and AS num. With ISP Network Engineer assistance they filled in ripe-219. Network Engineer sent it to Regional Internet Registry.
I have a feeling that we are trying to solve the poor performance of some players in this business with addressing policy. The easiest and best way for a customer to get resiliency is a) Get a provider that is a Tier-1 or have multiple upstreams b) Make sure you provider have a resilient network c) Get dual (really) connections to your provider. I assure you this will be cheaper than to get your own address space, LIR status, and God knows what. If a provider can't supply the above to a customer that really have the need for multiple connections and is willing to pay for it, I would change provider anyay. - kurtis -
On Wed, Oct 10, 2001 at 10:54:22AM +0200, Kurt Erik Lindqvist KPNQwest wrote:
But hadn't reached enough resilience level. They technical and marketing staff considered that without multihoming they can't achieve sufficient resilience level. They don't ready to pay for Enterprise LIR because they know about PI. They asked ISP to help them to obtain PI block and AS num. With ISP Network Engineer assistance they filled in ripe-219. Network Engineer sent it to Regional Internet Registry.
I have a feeling that we are trying to solve the poor performance of some players in this business with addressing policy.
The easiest and best way for a customer to get resiliency is
a) Get a provider that is a Tier-1 or have multiple upstreams b) Make sure you provider have a resilient network c) Get dual (really) connections to your provider.
I assure you this will be cheaper than to get your own address space, LIR status, and God knows what.
If a provider can't supply the above to a customer that really have the need for multiple connections and is willing to pay for it, I would change provider anyay.
There is one big issue: - you are ready to believe your "Tier-1 bla bla bla" provider for 24/7 non stop 100% quality of your Internet or - you are not Even in situation, when you can find close to you POP of reliable "Tier-1 bla bla bla" provider, two or more last mile providers, there always are people, who don't trust only one uplink. Psychology. Also pls don't forget about some geographical regions, covered by RIPE, where mostly impossible to build even one last mile channel to nearest "Tier-1 bla bla bla" provider for non-huge money. -- Regards, Vladimir.
If a provider can't supply the above to a customer that really have the need for multiple connections and is willing to pay for it, I would change provider anyay.
Also pls don't forget about some geographical regions, covered by RIPE, where mostly impossible to build even one last mile channel to nearest "Tier-1 bla bla bla" provider for non-huge money.
And in what way would my own AS number and PA space give me more last-mile providers? - kurtis -
On Wed, Oct 10, 2001 at 10:08:09PM +0200, Kurt Erik Lindqvist KPNQwest wrote:
If a provider can't supply the above to a customer that really have the need for multiple connections and is willing to pay for it, I would change provider anyay.
Also pls don't forget about some geographical regions, covered by RIPE, where mostly impossible to build even one last mile channel to nearest "Tier-1 bla bla bla" provider for non-huge money.
And in what way would my own AS number and PA space give me more last-mile providers?
Don't forget about cheap sattelite channels :-) Lets imagine situation - customer in a country, where all terrastical long- range channels are controlled by one big pro-government PTT. There isn't POPs of any of "Tier-1 bla bla bla" providers. All of them can be reached only by expensive long-rage terrastical or (less expensive) sattelite channel. 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. -- Regards, Vladimir.
Don't forget about cheap sattelite channels :-)
Lets imagine situation - customer in a country, where all terrastical long- range channels are controlled by one big pro-government PTT. There isn't POPs of any of "Tier-1 bla bla bla" providers. All of them can be reached only by expensive long-rage terrastical or (less expensive) sattelite channel.
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? 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.
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.
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. - kurtis -
And in what way would my own AS number and PA space give me more last-mile providers?
Potential for independence from any one supplier. Peter
The point was that there only was a single last-mile provider. Then a /8 and AS1 won't give you protection againt local-tail failures.
which is where, in my small experience, over 90% of the problems occur. randy
The point was that there only was a single last-mile provider. Then a /8 and AS1 won't give you protection againt local-tail failures.
And my point was that many ISPs will one use *one* last-mile provider each, in those territories where there is competition. So taking service from two selected ISPs will bring you services from two last-mile providers in turn. Most ISPs will *not* provide diversely purchased local-loop connections. Peter
And my point was that many ISPs will one use *one* last-mile provider each, in those territories where there is competition. So taking service from two selected ISPs will bring you services from two last-mile providers in turn.
Most ISPs will *not* provide diversely purchased local-loop connections.
This will vary alot, depending on country. In some countries, you will find one provider giving you redundant connections, you will find carriers using dual providers, and you will find countries that still have a PTT monopoly. There is not a "single" scenario. This however, does not mean though that multiple uplinks to more than one provider gives you more security than mulitple uplinks to one. - kurtis -
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. 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. Peter
a complete calls of failure modes associated with a single connection.
s/calls/class/ of course :) Peter
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.
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.
Well, teoretically this is certanly true. However, looking at reality, I don't think this is wort an extra entry in the global routing table, and where do this stop? How about the SOHO user that I described? Why are not they allowed broken up PA or PI space to be multihomed? - kurtis -
On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote:
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. ^ note the use of plural above. now read rfc 1930.
Randy, rfc1930 consists of 563 lines. I suppose you are talking about:
I think it's far simpler than that. Quoting (and guessing): To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. I.e. a provider (an AS) can only have a single routing policy. However, I also sense some language confusion above, and that what you're trying to say is actually "a simple multihoming situation where any one of the multiple uptstream providers' routing policy would be adequate for the client in question" However, I don't agree that it's a good idea to willfully cause the number of routes originated from different source ASes to increase. Furthermore, the routing complexity doesn't really rise as a function of the number of ASes -- it's rather the number of prefixes or perhaps rather the number of unique paths available which causes the entropy increase in the default-free zone which scares some of us. In the bigger picture it doesn't really make any difference whether the more- specific route comes from PI or PA space or whether the route is consistently originated from a new AS or (shudder) separately from the two (or more) upstream providers; the entrypy increase in the default- free zone would be the same either way. Regards, - Håvard
On Wed, Oct 10, 2001 at 10:04:22PM +0200, Havard Eidnes wrote:
On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote:
We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. ^ note the use of plural above. now read rfc 1930.
Randy, rfc1930 consists of 563 lines. I suppose you are talking about:
I think it's far simpler than that. Quoting (and guessing):
To rephrase succinctly:
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.
I.e. a provider (an AS) can only have a single routing policy.
However, I also sense some language confusion above, and that what you're trying to say is actually
"a simple multihoming situation where any one of the multiple uptstream providers' routing policy would be adequate for the client in question"
Yes.
However, I don't agree that it's a good idea to willfully cause the number of routes originated from different source ASes to increase.
If we are talking about theory -- agree, it's not a good idea.
Furthermore, the routing complexity doesn't really rise as a function of the number of ASes -- it's rather the number of prefixes or perhaps rather the number of unique paths available which causes the entropy increase in the default-free zone which scares some of us. In the bigger picture it doesn't really make any difference whether the more- specific route comes from PI or PA space or whether the route is consistently originated from a new AS or (shudder) separately from the two (or more) upstream providers; the entrypy increase in the default- free zone would be the same either way.
I agree with mentioned above statements about stability in "default-free zone". But (AFAIK) according to measurements and statistics amount of free AS-numbers are going to overflow more rapidly than free IPv4 address space. I believe that sometimes AS-numbers space will be extended, but (AFAIK) it requires global replacement of BGP-routing sotware. In this situation ?RIRs? are looking for ?temporary? solution how to decrease rate of AS-numbers allocation. One of such solutions (IMHO) is "more specific routes multihoming". I don't have exact information about other RIRs, but RIPE NCC already _promotes_ such solution. achieve multihoming) point of view adoption of such multihoming method, promoted by RIR, (sometimes) requires changes in routing policies and in what we are calling as "best practice". IMHO without new documents, recomendations, etc new multihoming method is (mostly) useless. Original posting was concerned in: - are there any already published/draft documents? - are there any plans to create such documents? If there aren't, and if community aren't going to accept such technology (from our discussion it seems that now there isn't common opinnion), IMHO, RIR "snake the air to no purpose" - such technology is (generally) useless. -- Regards, Vladimir.
Hi, please allow me some comments as seen from a LIR member (de.jippii former de.ipf) and now from an external point of view (consulting company for isps and ripe members)
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 ;-).
My observations show that RIPE NCC is quite able to judge it more or less efficiently. "More or Less" are defined as follows: - they take care about PA Assignments very well - they sometimes put too many questions for PA Space for bigger companies (like Banks, Cable Companies etc.) --> a seperate PA Proposal should be worked out how to handle with big multinational companies like banks or other companies. ARIN has dealt with a similar issue (but there we looking at CABLE Blocks) quite well - they are enforcing that every multihomed customer should be lir member(kind of) --> they shall create a new registry type called "multihomed but not isp" on which guidelines shall be established. this could solve some problems: - more direct contact between that customer <-> ripe - more "adress space clueness" at the customer side as past experience has shown, the isps are not 100% efficient in doing this; sorry. - would channelize the needs/wishes/possibilities from ripe and the customer. - would also cover some of the costs for running that kind of lir for ripe and generating more awareness at the "corporate" level.
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.
Which is REALLY bad, as seen from operator perspective, increasing the bloat of the routing table.
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":
right.
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.
it SHOULD belong only to one as. Other things are bad ("inconsistent routes").
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.
so this problem should be solved and addressed either with help of the IETF / IEPG and the LIR.
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".
By also looking at the "old SWAMP" space we also should look more into this. we are not able (till now) to efficiently clean the swamp space. either RIPE (with the LIR) should find possible scenarios for this address space, either revoking it from the old users, forcing them to renumber to more clear address space. This would also help to eliminate MANY /24 or /23 out of the routing table. It CAN be done, but only policies need to be defined. If a user still would like to use it internally (for some purposes like products registered on ip addresses) then NAT can be used with help of the isp. But the swamp space needs to be cleaned up!
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.
ACKED. i'm happy to help with the creation of such document.
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."
Well, seeing the recent discussion on NANOG, there exists quite a lot of technology which does not need announced /24 for load balancing (like RAD products). Just my .2 euro-cents :-)) -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
Hi, On Tue, Oct 09, 2001 at 07:28:48PM +0200, Jan-Ahrent-Czmok wrote:
- they are enforcing that every multihomed customer should be lir member(kind of) --> they shall create a new registry type called "multihomed but not isp"
There is a LIR category, called "enterprise LIR". Which is exactly what this is: a LIR that is only serving itself. [..]
By also looking at the "old SWAMP" space we also should look more into this. we are not able (till now) to efficiently clean the swamp space. either RIPE (with the LIR) should find possible scenarios for this address space, either revoking it from the old users, forcing them to renumber to more clear address space.
This is quite easy. Stop listening to it. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, 9 Oct 2001 20:45:02 +0200 Gert Doering <gert@Space.Net> wrote:
Hi,
On Tue, Oct 09, 2001 at 07:28:48PM +0200, Jan-Ahrent-Czmok wrote:
- they are enforcing that every multihomed customer should be lir member(kind of) --> they shall create a new registry type called "multihomed but not isp"
There is a LIR category, called "enterprise LIR". Which is exactly what this is: a LIR that is only serving itself.
Gerd, enterprise LIR would only cover the enterprises and banks, but not the small isp and cor- porations which are multihomed. enterpreise LIR is, AFAIK, also more expensive than small lir. Some providers are multihomed but cannot cover the costs, even for a small lir.
By also looking at the "old SWAMP" space we also should look more into this.
[...]
This is quite easy. Stop listening to it.
This would dump the traffic to the owners of these blocks (e.g. AFAIK xlink and RIPE) and SHOULD NOT be the correct way. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
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.
By also looking at the "old SWAMP" space we also should look more into this.
[...]
This is quite easy. Stop listening to it.
This would dump the traffic to the owners of these blocks (e.g. AFAIK xlink and RIPE) and SHOULD NOT be the correct way.
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. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote:
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.
Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay are very cheap. Also pls do not forget about PC+Unix+zebra/gated/etc solutions. They are still on the market. As example - we have one "multihomed" (PI /23) customer with 64K external uplink and 10Mb connection to local IX. -- Regards, Vladimir.
On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote:
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.
Surely there is more to being a LIR than simply as a way of buying a /20 for multihoming! RIPE is effectively a member-run organisation; being an LIR means taking part responsibility and getting involved via the working groups. The argument "buying the RIPE membership is cheaper than the router you need to run full BGP" basically sends a message that anyone with enough money can buy their own /20 and AS number without having to justify how they will use the address space, and without any obligation to the Internet community at large. Aled
Hi, On Tue, Oct 09, 2001 at 10:00:37PM +0100, Aled Morris wrote:
On Tue, Oct 09, 2001 at 09:29:54PM +0200, Gert Doering wrote:
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.
Surely there is more to being a LIR than simply as a way of buying a /20 for multihoming!
Yes.
RIPE is effectively a member-run organisation; being an LIR means taking part responsibility and getting involved via the working groups.
Yes.
The argument "buying the RIPE membership is cheaper than the router you need to run full BGP" basically sends a message that anyone with enough money can buy their own /20 and AS number without having to justify how they will use the address space, and without any obligation to the Internet community at large.
Which is not the way it should be (and it is not, according to policies), but you're twisting my sentence without quoting the statement above. Jan was complaining that it's too expensive to become a LIR. I put that cost into relation to the cost people have to pay anyway if they want to do *proper* multihoming, or put more precisely, be part of the default-free zone. And compared to that cost, becoming a LIR should be the least of your worries. I do not advocate that everybody that wants to have globally visible address space become a LIR. It is one way, for ISPs it's a good way (because it means you can handle address requirements of your customers in a practical and direct way), but for other entities it might be the wrong way. But *costs* are not a good criterium to decide that. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Jan was complaining that it's too expensive to become a LIR. I put that cost into relation to the cost people have to pay anyway if they want to do *proper* multihoming, or put more precisely, be part of the default-free zone. And compared to that cost, becoming a LIR should be the least of your worries.
.and as a brief sidenote: the ARIN community discussed the high entry level fee as an effective barrier to entry for obtaining globally unique prefixes. It was discussed that such a high cost helped protect the global routing table from "contamination" by those with no bona fide engineering goals and/or questionable motivations for injecting further routes. /david
On Wed, 10 Oct 2001 00:31:39 +0200 Gert Doering <gert@space.net> wrote: (..snip..)
Jan was complaining that it's too expensive to become a LIR. I put that cost into relation to the cost people have to pay anyway if they want to do *proper* multihoming, or put more precisely, be part of the default-free zone. And compared to that cost, becoming a LIR should be the least of your worries.
Well. Forcing PI owners to get involved within the RIPE would help all. Even sharing their experience (from business view) and teaching them (through ripe meetings & courses etc) would help everybody. And a "PI LIR" (NOT enterprise LIR) would bring some money back to RIPE helping the community as a whole.
I do not advocate that everybody that wants to have globally visible address space become a LIR. It is one way, for ISPs it's a good way (because it means you can handle address requirements of your customers in a practical and direct way), but for other entities it might be the wrong way. But *costs* are not a good criterium to decide that.
ACK, but it would solve a lot of problems. Solutions are not always good for all, but for most of all. Gerd, i think we should work more close together on this issue to address some of the issues as a draft to ripe. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
Hi, On Tue, Oct 09, 2001 at 11:17:25PM +0300, Vladimir A. Jakovenko 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.
Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay are very cheap.
"Multihoming" with something less than full tables won't really solve anything - as "multihoming without an AS number", it's some weird thing that has its place, but doesn't buy you much in the long run. (As for your example with the IX - this could be done without globally visible space just fine, it's not "multihoming") Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, 10 Oct 2001 00:21:09 +0200 Gert Doering <gert@Space.Net> wrote:
"Multihoming" with something less than full tables won't really solve anything
Right. - as "multihoming without an AS number", it's some weird thing
that has its place, but doesn't buy you much in the long run.
well. multihoming with private AS also could work. Combined with Conditional Announcement, it's a really useful possibility.
(As for your example with the IX - this could be done without globally visible space just fine, it's not "multihoming")
Well. IX space & DNS space is "IMHO" a special case which cannot be used on corporate or business isp. We need some clean-up in the "special" cases. Swamp Space, pre-RIR phases and more... When we cannot clean up the "swamp" from the past, can we do clean work in the future ? jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
On Wed, Oct 10, 2001 at 12:21:09AM +0200, Gert Doering wrote:
Hi,
On Tue, Oct 09, 2001 at 11:17:25PM +0300, Vladimir A. Jakovenko 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.
Are you sure? Old BGP-capable Cisco routers (like 25xx), especialy from eBay are very cheap.
"Multihoming" with something less than full tables won't really solve anything - as "multihoming without an AS number", it's some weird thing that has its place, but doesn't buy you much in the long run.
Please pay attention to _like_ in above statement. Ohh ... and about eBay: ttyp8 vovik@quiver:~>whois -h whois.radb.net 216.32.120.133 route: 216.32.120.0/24 descr: NET-EXODUS-EBAY-1 origin: AS3967 mnt-by: MAINT-AS3967 changed: radb@bengi.exodus.net 19981116 source: RADB route: 216.32.120.0/24 descr: NET-EBAY-1 origin: AS11643 notify: tholo@sigmasoft.com mnt-by: MAINT-AS11643 changed: tholo@sigmasoft.com 19981116 source: RADB Perhaps you are right, and this 'weird' thing was happened in 1998 by staff misunderstanding of how they should create route-objects. Right? :-)
(As for your example with the IX - this could be done without globally visible space just fine, it's not "multihoming")
It depends on IX routing policy. -- Regards, Vladimir.
On Tue, 9 Oct 2001 21:29:54 +0200 Gert Doering <gert@space.net> wrote:
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.
Sure ? Small providers tend to use open source software (like zebra) and have 2 x 10 or 2 x 100 Mbit/s to different providers, so your argument is not really true. But i understand your intentions, seen from provider perspective are right.
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.
I am not referring to 192.0.0.0/8, but in this case, we shall include an option to return old swamp space to their respective registry and issue address space from ripe.
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).
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Please do your homework about routing and BGP before selling people consulting about multihoming.
Ehm. IMHO, personal comments should be kept off-list. I am quite familiar with routing, BGP (and not just the usual i-know-routing-from-halabi lecture). I am currently finishing my CCIE. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
Jan-Ahrent-Czmok writes:
I am not referring to 192.0.0.0/8, but in this case, we shall include an option to return old swamp space to their respective registry and issue address space from ripe.
So what are you refering to? Please name examples of your wild claim: | This would dump the traffic to the owners of these blocks (e.g. AFAIK | xlink and RIPE) and SHOULD NOT be the correct way. In particular: - In which way is XLink special so that by dropping /24 routes, they would receive non-customer traffic? - RIPE announces exactly 193.0.0.0/21. So how would traffic magically end up at RIPE if you applied strict filters?
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).
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Nonsense again. Traffic will be blackholed only if you have *no* default route. Robert
On Tue, 9 Oct 2001 22:51:31 +0200 (MEST) Robert Kiessling <Robert.Kiessling@de.easynet.net> wrote:
Jan-Ahrent-Czmok writes:
I am not referring to 192.0.0.0/8, but in this case, we shall include an option to return old swamp space to their respective registry and issue address space from ripe.
So what are you refering to? Please name examples of your wild claim:
Okay, let's see if i find it: 192.124.115.0/24 == weblease AG, old address space from pre-ARIN, region should be ARIN/USA, is used in DE (okay -- no direct /16 or smaller announcement), but an example of the bad usage in the swamp space. inetnum: 194.13.111.0 - 194.13.111.255 route-server>sh ip bgp 194.13.111.0/24 shorter-prefixes * 194.13.0.0/17 12.123.25.245 0 7018 3549 1103 1103 i
In particular:
- In which way is XLink special so that by dropping /24 routes, they would receive non-customer traffic?
xlink used to keep some of the old swamp space overtook from uni karlsruhe
- RIPE announces exactly 193.0.0.0/21. So how would traffic magically end up at RIPE if you applied strict filters?
i am NOT referring to RIPE announced routes.
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).
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Nonsense again. Traffic will be blackholed only if you have *no* default route.
If you have a default route when multihomed, you create routing loops, when not filtering at both ends of the "transits". This created nice loops :-(( --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
So what are you refering to? Please name examples of your wild claim:
Okay, let's see if i find it:
192.124.115.0/24 == weblease AG, old address space from pre-ARIN, region should be ARIN/USA, is used in DE (okay -- no direct /16 or smaller announcement) [...]
Right. Routing is more or less orthogonal to assignment or allocation policies. There's no general route 192.0.0/8 in the default-free zone, so one or more providers in the default-free zone stopped listening to prefixes longer than, say /20, packets from those providers' customers towards e.g. 192.124.115.0/24 would be dropped on the floor by the first router along the path which didn't have a default route.
[...], but an example of the bad usage in the swamp space.
inetnum: 194.13.111.0 - 194.13.111.255
route-server>sh ip bgp 194.13.111.0/24 shorter-prefixes * 194.13.0.0/17 12.123.25.245 0 7018 3549 1103 1103 i
The routes 194.13.111.0/24 and 194.13.0.0/17 have different origin ASes, 1103 and 5409, respectively. My guess is that the originator of the 194.13.0.0/17 prefix is being a Good Guy, since he probably figures that he has the majority of the address space covered by that prefix, he originates that single /17 route instead of deaggregating to cover the exact address space he has allocated locally. If that /24 route should vanish from the network, traffic towards that prefix would be sent in the direction indicated by the enclosing /17, but there is in all probability no connectivity between the two networks, so the traffic would be dropped on the floor when it came within the zone of the /17-originators network (but the /24 route is gone, possibly due to an outage, so who cares?). And your point was what, again? Regards, - Håvard
On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote:
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Not necessarily. If you are multi-homed for redundancy reasons and have a small linux box with zebra your memory would be exhausted carrying to full route feeds. Two single default routes are far more efficient: at home I have cable and dsl. I have 2 tunnels to two different routers of my work. Over those tunnels I announce a /28 (which is aggregated to a /19) and receive two default routes. My dsl is faster so that has a higher local pref. If that goes down, the route switches over to the cable tunnel. -- Sabri Berisha ~~ my own opinions etc ~
On Tue, 9 Oct 2001, Sabri Berisha wrote:
On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote:
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Not necessarily. If you are multi-homed for redundancy reasons and have a small linux box with zebra your memory would be exhausted carrying to full route feeds. Two single default routes are far more efficient: at home I
Well, not exactly, 128 Meg can carry 2 full feeds, triple that and you have no worries.
have cable and dsl. I have 2 tunnels to two different routers of my work. Over those tunnels I announce a /28 (which is aggregated to a /19) and receive two default routes. My dsl is faster so that has a higher local pref. If that goes down, the route switches over to the cable tunnel.
-- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------
On Tue, 9 Oct 2001 23:30:47 +0200 (CEST) Sabri Berisha <sabri@bit.nl> wrote:
On Tue, 9 Oct 2001, Jan-Ahrent-Czmok wrote:
"if" you have a default route. Default route if multi-homed is surely bad IMHO.
Not necessarily. If you are multi-homed for redundancy reasons and have a small linux box with zebra your memory would be exhausted carrying to full route feeds. Two single default routes are far more efficient: at home I have cable and dsl. I have 2 tunnels to two different routers of my work. Over those tunnels I announce a /28 (which is aggregated to a /19) and receive two default routes. My dsl is faster so that has a higher local pref. If that goes down, the route switches over to the cable tunnel.
Well. I ACK your specific implementation. We are talking not about the small home user (or small business user). We are referring to ISP implementations here. In these ISP cases, when multihomed the "default route" is not a good idea, because of the danger of routing loops. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
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.
Sure ? Small providers tend to use open source software (like zebra) and have 2 x 10 or 2 x 100 Mbit/s to different providers, so your argument is not really true. But i understand your intentions, seen from provider perspective are right.
I think there are customers who have the need for redundancy but, not the need for a LIR. Actually a LIR is only needed if you have large amounts of address space to manage. That is at least always the way I have looked at LIRs. They have nothing to do with the routing policy. Now, you can have a small amount of address space, but sill have the need for resilience/redundancy/multiple uplinks. - kurtis -
participants (17)
-
Aled Morris -
Carlos Friacas -
David R Huberman -
Fredrik Widell -
Gert Doering -
Havard Eidnes -
Jan-Ahrent Czmok -
Jan-Ahrent-Czmok -
Kurt Erik Lindqvist KPNQwest -
lmb -
Mirta Matic -
Peter Galbavy -
Randy Bush -
Robert Kiessling -
Sabri Berisha -
Sascha E. Pollok -
Vladimir A. Jakovenko