Re: sub-basement multihoming (Re: Verio Peering Question)
| The "BGP uninformed" ask, "Why can't traffic just choose one of | two paths? The "BGP informed" ask that too. However, they know the technology isn't quite up to this worthy trick: | magic behind the scenes ... "just works", and all traffic should | be able to use all of their connections. ... except where that is not desired for policy reasons (e.g., don't use the volume-charged connection when the flat-rate connection isn't full). These are *hard problems*, unfortunately, and are still in the land of blue-sky research. Meanwhile, the problem is that the demand to do fancy routing things outstrips the Internet's current collective ability to supply it. As a result, we have to say "no" (or more $ than you can afford) to alot of things that seem worthwhile. One of those things is "low-value prefixes", independent of who announces them to the world. | I think that the demand is there -- current products just don't allow it. That's the crux of the problem, independent of whose "fault" it is that current products are not up to the task. Sean.
Date: Wed, 3 Oct 2001 07:45:00 -0700 (PDT) From: Sean M. Doran <smd@clock.org>
| The "BGP uninformed" ask, "Why can't traffic just choose one of | two paths?
The "BGP informed" ask that too. However, they know the technology isn't quite up to this worthy trick:
Which is the point that I thought I made. Thanks for clarifying.
| magic behind the scenes ... "just works", and all traffic should | be able to use all of their connections.
... except where that is not desired for policy reasons (e.g., don't use the volume-charged connection when the flat-rate connection isn't full).
These are *hard problems*, unfortunately, and are still in the land of blue-sky research.
Agreed. In your particular example, one has the additional problem of being a closed-loop system with state feedback. Let's add latency, CoS, and packet length. It gets messy quickly. Large, public interconnects could help address portability... but those have problems of their own. Note recent concerns about all eggs in one basket. Is IPv8 ready yet? ;-)
Meanwhile, the problem is that the demand to do fancy routing things outstrips the Internet's current collective ability to supply it. As a result, we have to say "no" (or more $ than you can afford) to alot of things that seem worthwhile. One of
Yes. Put bluntly, technology is not serving its users. It's the oil-burning '73 Nova that won't die: far from ideal, but it still runs, so we may as well use it instead of buying a new car...
those things is "low-value prefixes", independent of who announces them to the world.
| I think that the demand is there -- current products just don't allow it.
That's the crux of the problem, independent of whose "fault" it is that current products are not up to the task.
I'd also argue that RIR policies need a little new life breathed into them. IMHO, we're asymptotically approaching pre-CIDR days.
Sean.
Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Wed, 3 Oct 2001, E.B. Dreger wrote:
Meanwhile, the problem is that the demand to do fancy routing things outstrips the Internet's current collective ability to supply it. As a result, we have to say "no" (or more $ than you can afford) to alot of things that seem worthwhile. One of
Yes. Put bluntly, technology is not serving its users. It's the oil-burning '73 Nova that won't die: far from ideal, but it still runs, so we may as well use it instead of buying a new car...
I would really love to hear if anyone invented a way to do global routing with anything better than combination of flooding of aggregated reacheability information and defaut routes. It is not technology per se, it's the underlying concept which is barely adequate. --vadim PS I too have a pair of diverse DSLs and use combination of DNS (for ingress) and hash-based load sharing (for egress) packet routing. The resulting paths are sometimes hugely far from optimal.
PS I too have a pair of diverse DSLs and use combination of DNS (for ingress) and hash-based load sharing (for egress) packet routing. The resulting paths are sometimes hugely far from optimal.
Semi-OT: how do you get truly diverse DSLs? Don't they both go to the same CO? Grant -- Grant A. Kirkwood - grant@virtical.net Chief Technology Officer - Virtical Solutions, Inc. http://www.virtical.net/
On Wed, 03 Oct 2001 17:35:40 PDT, "Grant A. Kirkwood" said:
Semi-OT: how do you get truly diverse DSLs? Don't they both go to the same CO?
On Wed, 29 Aug 2001 19:38:33 PDT, Vadim Antonov said:
Teraplex 20 in full configuration (19.2 Tbps switching capacity, 128 racks) consumes 0.8 megawatt, not counting A/C.
Reminds me good ol' times when main Relcom POP in Moscow had an on-site nuclear reactor as a source of back-up electricity (well, it was located in the Kurchatov Institute of Atomic Energy :)
Maybe for anybody *ELSE* they'd terminate at the same CO, but I suspect the usual rules don't apply to Vadim. ;) /Valdis
Anyone ever try using the RADWARE LinkProof ? (or similar - are there any others ? ) <http://www.radware.com/content/products/link.htm> It looks like a combination between link monitoring & NAT'ing internal address the the "best" ISP's NetBlock Thanks - Rafi -- Rafi Sadowsky rafi@noc.ilan.net.il Network Operations Center | VoiceMail: +972-3-646-0592 FAX: +972-3-646-0454 ILAN - IUCC -I2(Israel) | FIRST-REP ILAN-CERT(CERT@CERT.AC.IL) (Israeli Academic Network) | (PGP key -> ) http://telem.openu.ac.il/~rafi On Wed, 3 Oct 2001, Vadim Antonov wrote:
On Wed, 3 Oct 2001, E.B. Dreger wrote:
Meanwhile, the problem is that the demand to do fancy routing things outstrips the Internet's current collective ability to supply it. As a result, we have to say "no" (or more $ than you can afford) to alot of things that seem worthwhile. One of
Yes. Put bluntly, technology is not serving its users. It's the oil-burning '73 Nova that won't die: far from ideal, but it still runs, so we may as well use it instead of buying a new car...
I would really love to hear if anyone invented a way to do global routing with anything better than combination of flooding of aggregated reacheability information and defaut routes.
It is not technology per se, it's the underlying concept which is barely adequate.
--vadim
PS I too have a pair of diverse DSLs and use combination of DNS (for ingress) and hash-based load sharing (for egress) packet routing. The resulting paths are sometimes hugely far from optimal.
On Sat, Oct 06, 2001 at 01:15:41AM +0200, Rafi Sadowsky wrote:
Anyone ever try using the RADWARE LinkProof ? (or similar - are there any others ? )
<http://www.radware.com/content/products/link.htm>
It looks like a combination between link monitoring & NAT'ing internal address the the "best" ISP's NetBlock
I have not in fact used the product, but I was invited to a presentation with lots of technical details. I then went for beers with a couple of the techies, which was quite educational too :) The way it works is as follows: - you put all your servers that you want redundant (it is hardly protocol-specific, which is good) in RFC1918 space. - you hook up to a couple of ISPs, and get from each a block the same size as your RFC1918 block. - you delegate DNS for any service you want redundant to the linkproof box/boxes (they can failover amongst themselves), one NS+A record for each ISP you have space from. The inherent failover in DNS caches/resolvers makes sure clients will always at least get a reply (this is the neat bit - the real failover is in DNS resolvers everywhere, not in the box itself). - the box, continually monitoring rtt's and reachability of networks, returns the A record pointing to the most 'optimal' ISP for that client. This request then comes in, it NATs it to the RFC1918 space and handles it. The neat thing is that it does not need a netblock big enough to get through BGP filters - you just get a /24 or whatever from *each* ISP, out of their larger netblocks. The concept is nice, it sounds like it will work. I have, however, never tried it so I can't vouch for the implementation. Greetz, Peter [not affiliated with RadWare or anything] -- Monopoly http://www.dataloss.nl/monopoly.html
On Sat, Oct 06, 2001 at 01:31:47AM +0200, Peter van Dijk wrote:
- the box, continually monitoring rtt's and reachability of networks, returns the A record pointing to the most 'optimal' ISP for that client. This request then comes in, it NATs it to the RFC1918 space and handles it.
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data. Each one responds with data relevant for the IP addresses of that ISP. If all your links are up, people will get mixed responses. If one ISP is down, that nameserver will stop answering, and hence after your TTL expires, no requests will be made for those IP addresses. It gets even better - recursing nameservers have the habit of locking in to nameservers that respond quickest. So you even get some loadbalancing awareness. We operate nameservers in the US and in Europe, and we definitely see this effect. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services Trilab The Technology People Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
Date: Sat, 6 Oct 2001 19:17:39 +0200 From: bert hubert <ahu@ds9a.nl>
(top-posting due to length of original post) Alas, the "after your TTL expires" is a killer. I don't want to resurrect a thread that has been covered in the past couple of months, but DNS just doesn't cut it for failover. Furthermore, fast DNS response != fast HTTP response. {Swamp space|non-Verio filtering policies} and BGP are the way to approach this. For redundant DNS at a single site, IP and MAC takeover are what one wants. All IMHO. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ---------------------------------------------------------------------------
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
Each one responds with data relevant for the IP addresses of that ISP. If all your links are up, people will get mixed responses. If one ISP is down, that nameserver will stop answering, and hence after your TTL expires, no requests will be made for those IP addresses.
It gets even better - recursing nameservers have the habit of locking in to nameservers that respond quickest. So you even get some loadbalancing awareness.
We operate nameservers in the US and in Europe, and we definitely see this effect.
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Date: Sat, 6 Oct 2001 19:17:39 +0200 From: bert hubert <ahu@ds9a.nl>
[ snip ]
It gets even better - recursing nameservers have the habit of locking in to nameservers that respond quickest. So you even get some loadbalancing awareness.
Odd. I've investigated this effect (well aware of it in theory) with stateside-only machines, and DNS frequently returns a horrible choice. Maybe caching prevents enough authoritative answers from being returned to cancel out the noise, but I've seen the opposite of what you report.
We operate nameservers in the US and in Europe, and we definitely see this effect.
Maybe it works well over different continents, but simple "use different IPs from different NS" has not given desirable results in my experience. Then we have the failover and TTL issues... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (8)
-
bert hubert -
E.B. Dreger -
Grant A. Kirkwood -
Peter van Dijk -
Rafi Sadowsky -
smd＠clock.org -
Vadim Antonov -
Valdis.Kletnieks＠vt.edu