North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Alternative to BGP-4 for multihoming?
At 16:44 12/03/00 -0500, Peter A. van Oene wrote: After knocking the Linkproof, I started to dig deeper and do believe that for certain sites it does provide a solution. Things that BGP can't do, like load the links via either least traffic, round robin, or least flows; checking proximity via hops, latency and load - and each of these variables the user can assign a weight; supports routing for RIP II or OSPF, and a bunch of other features. Yes, it has some warts (sends out dns with ttl=0 which not everyone will like; sends out 2 A records (if enabled) for all queries), is not approrpriate for huge sites, but for small sites that have 2-3 T1s in use via BGP, this may be solution. BGP was never meant to be a load balancing method. To quote from the RFC: Since BGP picks a ‘best’ route based upon most specific prefix and shortest AS_PATH, it becomes non-trivial to figure out how to manually direct specific portions of internal traffic (prefixes) in a distributed fashion across multiple external gateways. We all know how hard it is to play with AS-path lengths and to get the links close to a 40-60% split. These black boxes provide a different option and a possible solution. I intend to have a customer test one for a period of a month and can report back here what we find. -Hank PS Anyone who wants the 392K PDF Users Manual for Linkproof can send me private email and when I have time I will ship it out. > >This is great feedback / moderate flaming. However, consider the >following. > >I have only moderate experience with the F5 3DNS & similar products however >I am familiar with BGP routing. My client base are high traffic e-commerce >style (for lack of a better over used marketing term) web sites. They sit >on /28's and smaller in some cases. I'm certainly not going to be >successful in acquiring ASN's for these people to do proper load balancing >between multiple ISP's and most major ISP's see little benefit in modifying >route tables to include our small netblock. Its these cases I'm concerned >with. In my mind, irrespective of the comments on the functionality of DNS >for this purpose, I see little other choice. > >As a direct FYI, the 3DNS can make fairly intelligent decisions about where >to direct traffic beyond simply gauging TCP/53 handshake times. These is >quite a detailed, informatative interaction that can take place between the >3DNS and F5's local load distributor, the BIG-IP. > >That being said, if anyone has better ideas on how to provide for high >availability to millions of web sites worldwide, please let me know. > >Pete > > >*********** REPLY SEPARATOR *********** > >On 3/12/00 at 1:32 PM Chris Brenton wrote: > >>"Peter A. van Oene" wrote: >>> >>> Essentially, the 3DNS box assumes the DNS entry for the site for which >the >>> customer requires multihoming and it intelligently balances traffic >amongst >>> any geographically disparate sites. This allows for high availability. >> >>If I'm not mistaken, it accomplishes this in a somewhat obtrusive >>manner. The box attempts an xfer back to TCP/53 on the querying DNS >>server. Based on response time, a proper route is chosen. I've seen a >>lot of posts to Intrusion & GIAC from people who assumed someone was >>trying enumeration in preparation for an attack, only to find out it was >>one of these boxes. >> >>I also seem to remember a post on GIAC showing Snort traces of one of >>these boxes actually performing a full xfer if the box was not locked >>down. Do you use one of these boxes? If so, any idea what happens to the >>xfer data? >> >>Ignoring the argument as to whether its appropriate to attempt xfers on >>unsuspecting networks, I also see this as being pretty inefficient. A >>good quantity of sites are now running split DNS so the querying server >>is not even reachable. This means a fair percentage of the time the load >>balance attempt will outright fail. >> >>Don't see this replacing BGP anytime soon. ;) >> >>Chris >>-- >>************************************** >>[email protected] >> >>* Multiprotocol Network Design & Troubleshooting >>http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet >>* Mastering Network Security >>http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet > > >------- >Peter Van Oene >Senior Systems Engineer >UNIS LUMIN Inc. >www.unislumin.com > > >