North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Alternative to BGP-4 for multihoming?
- From: Hank Nussbacher
- Date: Mon Mar 13 03:16:50 2000
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.
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
>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.
>*********** 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
>>> customer requires multihoming and it intelligently balances traffic
>>> 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
>>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. ;)
>>* Multiprotocol Network Design & Troubleshooting
>>* Mastering Network Security
>Peter Van Oene
>Senior Systems Engineer
>UNIS LUMIN Inc.