Defining "better" when all you have to work with is BGP, is pretty hard. It turns out that, as in DNS, round robin is better than any definable static ordering.
You can say that again! Actually, one of the critical performance criteria for our network is how fast we can get rid of packets going to end users, so path "goodness" is pretty serious issue for us. I sure wish there were some way (better than BGP I mean) for routing packets in a multi-homed environment. However the technique we use is twofold: 1) we've built into our product the ability to load balance on a failure (or a really bad delay situation), away from a serious problem either in a server, or conceivably in the path. This happens under the covers and we're only dimly aware of it, unless there's a big problem somewhere. The usual reason this occurs is a reachability problem through one ISP or another, or running out of bandwidth into an ISP. 2) we observe the gross characteristics of our ISPs as seen from our end, and "push" more traffic towards networks with better delay and reliability characteristics. Unfortunately, this is a somewhat manual process. We are looking for "more automatic" ways of doing this, if people know of pointers to good "network quality measurement" stuff, point me at 'em. Our ISPs seem to do a fair to reasonable job of preventing their networks from cracking up, however we often can take load off an ISP while they fix a problem that crops up in their network (and usually do to improve quality of service to our end users, if we have the bandwidth to spare). I'd love to know if there are other multihomed sites out there that have successfully gotten full BGP information from multiple providers and used it to balance outgoing load, and had positive experiences as a result. Given all the problems of using BGP for this purpose (for which it really wasn't designed), we've wondered how hard we should push our providers to do this. (Some will, some won't, although I suspect we could get them all to if we really wanted). Best regards, -jcp-