Cisco Blogs

Service Capacity Planning at Cisco

Capacity planning is getting far more complicated as network services get more complex, and it requires understanding each service as a whole, cutting across several traditional IT services like network and data center capacity planning.  Here’s how Cisco IT is starting to address these new service-based capacity issues, mainly focusing on Network and Voice Capacity Management

 Cisco IT design and support teams are divided into regional and global technology areas.  Campus LAN and regional WAN support are handled by one of four different regional teams around the world.  Other services – the global network backbone, data center support, wireless services, Extranet services, and others, as well as collaboration services like voice and video and web conferencing – are supported by global teams. 

 In the past, capacity planning was handled by each team, acting separately.  If a WAN link or a voice gateway or a data center floor was reaching full capacity, that team would identify the issue and set about dealing with it.  When IT services were mostly providing a set of working applications in the data center and providing the network required to connect to them, this relatively simple and fragmented capacity planning process worked fine.  But as services got more complex and more interconnected, Cisco IT needed to take an overall Capacity Management service view, looking at the architecture as a whole and all the services within that architecture, to make sure that we provide the capacity to support our business services.  We also need to be more proactive, as we deliver services like networked video or data center storage, which use so much in the way of costly IT resources and are growing so quickly, and are critical to the smooth functioning of our business, while only installing as much of these costly resources as needed.

 An excellent example of a complex service requiring an architectural service view is Webex conferencing.   Webex conferencing allows groups of Cisco employees to meet and share a lot of information – sharing laptop screens and presentations, combined with voice and video conferencing, and also allows the meeting host to record the meeting to share with people who couldn’t attend.  Webex conference usage has been growing rapidly at Cisco as we work more globally, and also as we try to reduce our travel spending

This rapid growth in Webex conferencing is adding a lot more voice traffic to the network, and changing its direction as well.  People used to dial into a meeting bridge – increasing inbound traffic; but as people use the callback function from the Webex voice bridges in San Jose (and soon in London, as well) to dial back to their phones – office phones, home phones, mobile phones—our outbound traffic has increased dramatically.  All this Webex conferencing usage also generates network traffic as people are sharing screens and presentations and video streams over the WAN.  And as more people are recording their calls (at around 25-30MB per hour of recorded conference call) on the shared Webex storage frames, storage capacity is becoming an issue too, at a time when Cisco data centers are so full that it is forcing a major migration to new data centers worldwide. 

But what really drives Cisco IT to a “service” point of view is that we cannot manage Webex in pieces any more.  Each piece – voice, video, web, and data center storage – all come together to make up the conferencing experience.  If voice or video is bad, or screen sharing fails, or you can’t record the meeting, people will be unhappy with the service.  And measuring the capacity and quality of the Webex requires knowing the capacity and quality of each of these areas of the service – down to knowing which voice queues and gateways used by Webex are doing, how the servers and storage available to Webex are doing, and so on; and only when we can monitor, track, and do capacity planning for all of these traditional IT services together can we be certain that we are delivering good service.   We can still measure the WAN capacity, and that of voice, and of the data center, as separate IT components; but we have to start thinking about them, and managing capacity, as parts of a large set of business services, at least from a planning perspective.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Are you (i.e., Cisco) using any modeling in your process? I was reading a recent article about using queuing networks on higher-speed links and seeing a reduction in the packet train”” errors due to the no smaller percentage of the total each train uses up…And, of course, numerical simulations like JMT continue to work, albeit slower.–dave (a metrics nerd) c-b”