Rapid growth

I read an article by Greg Ferro about twenty-percent-growth recently.  Greg makes the point that most network growth forecasts are grossly overoptimistic.   However, my experience in the service provider world is that ‘the business’ underestimates growth in most cases.
Network engineers have a fiscal responsibility not to gold-plate their network designs; network gear is just too damn expensive.  But you can over-optimise for cost.  It is incredibly frustrating to overhaul and scale-up a network within a year of the initial deployment.    The end-result is additional capital cost, more engineer effort and resultant opportunity costs.

Challenge requirements

Before you commit to a design, it is your duty to challenge the requirements.  At the very least ask yourself and the business the following questions:

• Where did this growth estimate come from?
• Should I believe this growth esimate?  Is there a track record of over (or under) estimation?
• Are you aware of any other factors that might influence demand e.g. other projects?

Thinking ahead

Each and every network design document should highlight the known scaling limits of the proposed design.  More importantly, the design should have a section called ‘next scaling options’, outlining what a larger-scale design would look like.   This is really, really important as it shapes your current design and helps you build a network that is ‘designed to scale’.

Finance says no

If you believe that you will need to scale a network again within one year, you should push to deploy the larger-scale design up front.  However, your finance team will want to preserve cash-flow and spend just before your network starts to bleed.  The finance team often has the final word and will likely demand the smaller short term solution.

Hedging against rapid growth

Don’t give up though.  I’ve listed some design options below that help cut costs without causing future scaling headaches.

Stackable

Could you buy a single 3750X rather than a single 3560X? Getting the stackable variant isn’t that much more than the standalone switch.  You run out of ports… no problem .. buy a switch and stacky-stacky.   Don’t take the piss here though, large stacks are a pain in the neck!
The twingig adaptors Cisco provided on the 3750E were a great example of hedging for growth.  Just run with the switch with two 1Gbps SFPs for now, then swapout for a 10G X2 transceiver when 10G demand arrives.

Skeletal Chassis

What if you’re set for explosive growth, but still getting budget pressure?  For example;  if you truly think you will need a nexus 7018 in the next year, then don’t deploy a nexus 7010 to keep finance happy.   You know you’re never going to get that 7010 out of the network, not gonna happen!  Better to deploy a stripped-down nexus 7018 design with minimal line cards.  Subsequent scaling is easier and cheaper and you end up with the network you wanted in the first place.

Little brother

Other times, the seemingly ‘obvious’ choice for cost reduction is to collapse your ‘large-scale’ network and remove layers of hierarchy.   Assuming that your initial design was justified, you should resist this temptation to collapse a core layer into an agg-layer.  Inserting a new layer of hierarchy into an operational network can be torturous.  What about little brother?  Could you scale down your L3 core layer instead of removing it?  What about a 4900M or nexus 3064 instead of a nexus 7010?

Cabling Hacks

Last but not least,  think of the cabling.  Cabling is a large proportion of the infrastructure budget.  Often the labour costs can be a large sub-set of these costs, and re-work is expensive.   If you’re pulling cable or terminating fiber, how much extra would it cost you to pull additional pairs to accommodate the large-scale design?  Don’t go crazy here, but check out the options when seeking a quote.

Conclusion

I hope the tips above can help you when you’re working in a rapid growth environment.   With a little bit of forward planning and judgment you should be able to remove a lot the growing pains.
How to you manage to balance budget against build?  Disagree?  I’d love to hear from you in the comments.