[86551] in North American Network Operators' Group
Re: Comments or suggestions required Internap FCP 500 vs. OER
daemon@ATHENA.MIT.EDU (Tom Sands)
Thu Nov 10 08:11:52 2005
Date: Thu, 10 Nov 2005 07:11:23 -0600
From: Tom Sands <tsands@rackspace.com>
To: Matt Buford <matt@overloaded.net>
Cc: Drew Weaver <drew.weaver@thenap.com>, nanog@merit.edu
In-Reply-To: <005301c5e5a4$9f0af5a0$0261a8c0@speedy>
Errors-To: owner-nanog@merit.edu
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
------------------------------------------------------
