Capacity planning and dependency mapping: bandwidth, growth and critical paths

Two questions every architecture must answer

A network design can look perfect on paper and still fail in daily use. Two questions catch most problems early. First, is there enough capacity, now and in two or three years? Second, what depends on what, so that you know which single failure would stop the business? The first is capacity planning; the second is dependency mapping. Both turn the design into numbers and lists you can check.

Measuring a baseline

You can't plan without knowing today's usage. Collect interface statistics from switches, routers and firewalls for at least a few weeks, using SNMP polling, streaming telemetry or flow records such as NetFlow or IPFIX.

• Look at peaks, not averages. A link that averages 20% may hit 95% every morning when backups overlap with logins. Many teams use the 95th percentile: the level that usage stays below 95% of the time.
• Separate directions. Upload and download are measured separately; a branch's uplink is often the busier side because of video calls and cloud backups.
• Know which applications use the bandwidth. Flow data shows whether a busy link is carrying business traffic or software updates.
• Watch more than links. Firewall throughput with inspection turned on, VPN tunnel limits, Wi-Fi airtime and DHCP pool sizes run out too.

Forecasting and sizing

Forecast from business plans as well as trends: a new office, a move to cloud backups or a camera upgrade can double demand overnight. A common rule of thumb is to plan an upgrade when the busy-hour 95th percentile passes about 70% of a link, because queues and delay grow quickly above that point.

Oversubscription is normal and acceptable: not every user sends at full speed at once. An access switch with 48 gigabit ports and two 10 Gbit/s uplinks has a ratio of 48:20, or 2.4:1. Typical targets are around 20:1 or lower from access to distribution, around 4:1 from distribution to core, and much lower in data centres where servers talk to each other constantly. Use the bandwidth calculator to check transfer times for large jobs such as backups.

Tip: include failure in your sums. If two links share the load at 60% each and one fails, the survivor needs 120%. Size redundant links so that one can carry the essential traffic alone.

Dependency mapping and critical paths

A dependency map lists everything one service needs to work, layer by layer. For a cloud payroll system that might be: the user's laptop and Wi-Fi, the access switch, the DHCP and DNS servers, the identity provider for sign-in, the branch firewall, the internet link and the SaaS provider itself. The critical path is the chain of components that every request must pass through. Any component on it without a backup is a single point of failure.

1. Pick the services the business can't run without.
2. For each, trace a request from the user to the application and back, listing devices, links and supporting services (DNS, DHCP, authentication, NTP, certificates).
3. Mark which items have a working backup and which don't.
4. Rank the single points of failure by impact and fix the worst first, or accept and document the risk.
5. Keep the map up to date as part of change management.

Shared services such as DNS and identity often appear on every critical path, which makes them more important than any single link.

Real-world example: a hospital imaging upgrade

A fictional regional hospital planned to replace its imaging scanners with models that send far larger image files to the archive in the data centre. The network team measured the radiology floor for a month and found its two 1 Gbit/s uplinks peaking at 65%. The new scanners would add several times that load, so they upgraded the uplinks to 10 Gbit/s before installation, not after complaints. Their dependency map for the imaging system also showed one DNS server and a single firewall in front of the archive. They added a second DNS server and a firewall pair, then tested failover during a planned maintenance window.