Matt Buford wrote:
We're looking at possibly purchasing a Internap FCP500, everything I hear about these boxes is good. We are simultaneously
I have no experience with OER, but I have had a FCP5000 for a while now. We have numerous transit links, all of which have significantly more burst capacity than we actually use (or commit to). To some extent it is a bit magical and I don't always understand how it decides the "target" traffic level for a link, but in general it works great. Since installing it we've pretty much done away with any other regular BGP changes to balance traffic. It does a good job of keeping out many transit links all below commit unless total traffic exceeds all commits.
We've used the FCP500 and FCP5000 for several years now, and though we have had our ups and downs in terms of hardware failures, bugs, and capacity concerns. I must agree that it does a very good job at the basics of balancing out traffic for commits, bursting (based on cost) and minimally for performance. If you have transit and peering, there are some things about it that don't fit real well into that model.
In general, I'm skeptical that it is really providing much of a performance boost. However, it does a good job at balancing traffic levels and that is the main value we get from the product. It was basically a "fire and forget" system. Once installed, we were able to just forget about traffic engineering and only touch things when adding/removing a link (or for special situations like manually routing around bad paths).
If you'd like technical information about how it works or the potential scaling issues that can result let me know what you're interested in and I can expand a bit.
-- ------------------------------------------------------ Tom Sands Chief Network Engineer Rackspace Managed Hosting (210)447-4065 ------------------------------------------------------