North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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
>>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. ;)
>>[email protected]
>>* Multiprotocol Network Design & Troubleshooting
>>* Mastering Network Security
>Peter Van Oene
>Senior Systems Engineer