On Sun, Jun 12, 2016 at 9:49 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 13 Jun 2016, at 8:52, Kasper Adel wrote:
2) Do some planning and research first.
This.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
We never design in a vacuum. There's always some target we're designing towards. Testing is no different. Think about what it is you'll need to support. Look at historical numbers related to those features/capabilities. Yes, as the stork market keeps reminding us, past performance is no guarantee of future results...but at the same time, those who don't learn from the past are doomed to re-implement it...poorly. So, when we test, we look at protocols we've already been running for years, and then we look at the growth curves we've seen in those protocols over the past X years, where X is approximately the estimated lifespan of the hardware in question. So, if the current router platform you're looking to replace has been in place in your network for 8 years, and you're testing the next generation for BGP route scaling, look at what the global BGP table size was 8 years ago, and look at where it is today; work out the percentage growth curve for it; then take the current BGP table size, apply the same compound growth percentage to it for the next 8 years, and you'll come up with a reasonable idea of the scale you'll need the box to handle over its lifetime. Test that; then, to give yourself a margin of error, double the number, and test again. That way you have a realistic idea of whether it can support your current growth rate, and whether it can support your growth if the growth rate is 1.4x what you expect. Do those calculations for each of the protocols under test, and you'll be able to come up with a reasonable testing profile that's supportable based on historical information, rather than flights of fancy. Hope that helps! Matt