However, the truth is that we have outgrown our FCP. YMMV with the product...
Why is that? What particular problems did you run into?
Since I've opened the can of worms...
The FCP integration requires direct capturing of traffic off of your network. This would either be a off of a port mirror or off of network taps.
We had some challenges, basically because of our architecture, implementing the solution at first. We had a rather collapsed network with service access and peering in the same router in some cases. Also, our routers were not capable of mirroring traffic at L2.
Including any geographically diverse peering sites may be challenging. Options include another FCP, an FCR (remote packet capture device), or transporting the mirrored/tapped traffic back to the FCP location. I believe sampled flow data may have been an option, but was not a recommended approach.
The preferred method of enabling communication between the FCP and peering routers for routing manipulation is to create GRE tunnels between those. Our routers did not support GRE as a base option or at all (multiple vendors/models). Other options are available that we did not explore fully.
We have since "cleaned up" our architecture, but are also growing to a much larger number of ports and to 10Gbps. Also, we'd like to have more insight into traffic between our various service PoPs and not just at our transit/private peering edges. Significant hardware investment would be required to scale to this level.
All that being said, the Internap Implementation team was very helpful and patient throughout. If you do go with this solution, you'll have a good set of allies at Internap helping you throughout the project.
Regards,
Mauricio Rodriguez
Manager of IP/Data Engineering, FPL FiberNet
Email: Mauricio.Rodriguez@fpl.com