Holiday traffic doesn’t just mean more traffic. It means a genuinely different mix of traffic — streaming and e-commerce spike sharply, business application usage often drops, and both can happen at the same time on the same network. Planning for the holiday season as “add more bandwidth” misses the actual engineering problem: the composition of traffic changes in ways that standard capacity forecasting, tuned for a normal business week, doesn’t account for.
This guide walks through how to actually plan for that shift, covering bandwidth budgeting by application mix, QoS adjustments, SD-WAN routing policy, VPN gateway scaling for a holiday remote workforce, the security threats that spike during this period, and how to make maintenance changes you can safely roll back if something goes wrong.
Why Holiday Traffic Breaks Standard Forecasting Models
Most capacity planning assumes traffic grows roughly in proportion to historical trends, scaled for expected growth. Holiday traffic doesn’t follow that pattern, because it’s driven by a sudden shift in what people are actually doing, not steady growth.
Akamai’s holiday traffic data gives a concrete sense of the scale involved. During Thanksgiving weekend, U.S. video delivery on Thanksgiving morning ran 65% above the prior week, with an evening dip before another surge. Black Friday e-commerce traffic measured 57% above typical levels, and Cyber Monday traffic rose 48%, with mobile devices accounting for 63% of Black Friday e-commerce activity. Bot traffic targeting e-commerce sites also rose 18% in the weeks leading up to Cyber Monday, peaking with 30% more activity than normal days on both Thanksgiving and Cyber Monday itself.
These are published, sourced figures from Akamai’s own traffic analysis, not internal guesses — and they illustrate the core planning problem well: a network sized for “normal plus some growth” can be caught badly off guard by a traffic mix that shifts this sharply, this fast, in both volume and composition.
Building a Holiday Network Traffic Planning Timeline
Treat holiday network traffic planning as a project with its own deadline, not an afterthought bolted onto normal change-management cycles. A realistic timeline starts gathering prior-year flow data and reviewing last year’s incidents roughly six to eight weeks out, drafts and tests QoS and SD-WAN policy changes three to four weeks out, and finalizes VPN sizing and MFA enforcement two weeks out, leaving the final week for a dry run of the rollback process rather than last-minute configuration changes.
Bandwidth Budgeting for the Holiday Application Mix
The planning question isn’t just “how much more bandwidth,” it’s “bandwidth for what.” Business application traffic (ERP systems, internal collaboration tools, VPN-based remote work) commonly drops during the holiday weeks as offices run with reduced staffing, while consumer-facing traffic — streaming, e-commerce, and general web browsing from remote or on-site staff during slow periods — tends to rise.
Mapping Application Profiles to Link Utilization
Before the season starts, it’s worth pulling actual flow data (via NetFlow, sFlow, or a tool like ntopng or PRTG) from the prior year’s holiday period, if you have it, rather than guessing at the mix. If you don’t have prior-year data, build a conservative estimate based on your organization’s actual remote-work policy for that period and known streaming/browsing allowances, and treat it as a hypothesis to validate against real monitoring once the season begins, not a fixed number to set and forget.
QoS Re-Engineering for the Holiday Application Mix
A QoS policy tuned for a normal business mix may not reflect holiday-period priorities correctly, especially if streaming and general web traffic from reduced on-site staff competes for bandwidth that’s normally reserved for business applications.
A Minimal QoS Refresh Before the Holiday Rush
One important technical correction here: classifying traffic by matching on HTTP host headers (match protocol http host <name>) only works for unencrypted HTTP traffic. The overwhelming majority of streaming services now serve video over HTTPS, where the host header isn’t visible to a simple inline device without TLS inspection.
Realistic classification options for encrypted streaming traffic generally rely on DPI-based application recognition (built into many next-generation firewalls and some router platforms), DNS-based classification (matching the destination domain before the encrypted session starts), or marking based on known destination IP ranges published by major streaming and conferencing providers. Whichever method you use, test it against actual encrypted traffic before trusting it for a holiday rollout — a classification rule that silently fails to match anything is worse than no rule at all, since it gives false confidence.
<!– INFOGRAPHIC: Holiday Network Traffic Planning Checklist goes here –>
SD-WAN Policies That Adapt to Holiday Routing Changes
If your organization uses SD-WAN, holiday-period policies typically need to account for a different balance between business-critical and general internet-bound traffic. Cisco’s Catalyst SD-WAN platform (built on the former Viptela architecture, managed through the Catalyst SD-WAN Manager controller) supports time-based and application-based policy changes that can shift path preference and bandwidth allocation for a defined window, though the exact configuration syntax varies by platform version — always verify against your specific controller version’s current documentation rather than copying a generic example, since SD-WAN configuration syntax changes meaningfully between major releases.
Planning a Holiday Traffic Policy
Whatever platform you use — Cisco Catalyst SD-WAN, Fortinet FortiOS SD-WAN, or another vendor — the planning steps are similar: identify which applications get priority path selection during the holiday window, confirm your policy engine actually supports time-bound activation (not all do natively, and some require a scheduled manual toggle instead), and test the policy change in a maintenance window before the holiday period actually begins, not during it.
VPN Gateway Scaling as Part of Holiday Network Traffic Planning
Remote access patterns shift during the holidays too, sometimes upward (if staff work remotely over the holidays rather than taking full office time off) and sometimes downward (if most staff are simply off). Which direction applies depends entirely on your organization’s actual holiday policy, so check your own historical VPN session data from show vpn-sessiondb summary (on Cisco ASA) or your platform’s equivalent, rather than assuming either direction by default.
Right-Sizing the VPN Pool
Most VPN concentrators and firewalls have a hard session limit, and behavior when that limit is reached varies by platform and configuration — some reject new sessions outright, others may have configurable overflow handling. Check your specific platform’s documented behavior at the session limit rather than assuming a universal outcome, since getting this wrong during an actual holiday surge is exactly the kind of problem you want to catch in testing, not live.
Network Security as Part of Holiday Network Traffic Planning
Phishing and other social-engineering attacks commonly increase during the holiday season, often themed around shipping notifications, gift cards, or charity donation requests, taking advantage of a period when staff may be more distracted, working with reduced IT support coverage, or simply expecting more legitimate shipping and retail emails than usual. This is a well-documented seasonal pattern across the security industry generally, even where a specific year-over-year percentage isn’t something I can verify without a direct link to a named report.
Enforcing Multi-Factor Authentication on All Remote Access
If MFA isn’t already mandatory on all remote access paths, the run-up to the holiday period is a sensible time to close that gap, precisely because reduced staffing and higher social-engineering activity compound each other’s risk. Platforms like Duo integrated with FortiOS, or equivalent MFA integrations on other VPN platforms, are common ways to enforce this without requiring users to change their actual login workflow significantly.
Maintenance Windows: The Final Piece of Holiday Network Traffic Planning
Any configuration changes made ahead of the holiday period should go through a process that’s safely reversible, given how much less IT staff coverage is typically available if something goes wrong during the actual holiday window.
Building a Safely Reversible Change Process
Platforms differ in how they handle this. Junos supports a rollback and rescue-configuration model that lets you revert to a known-good state relatively quickly. Many Arista EOS deployments support a similar configuration-session/rollback workflow, though the exact command syntax should be verified against your specific EOS version. For Cisco IOS-XE, archiving the running configuration before any change (via the archive feature, configured with a real, valid timestamp-based or sequential file-naming scheme per your platform’s documented syntax) gives you a known point to return to. Whatever platform you’re on, test the actual rollback process once, well before the holiday period, rather than assuming it will work correctly the first time it’s actually needed under pressure.
Monitoring During the Holiday Window Itself
Holiday network traffic planning doesn’t end once the configuration changes are deployed — the holiday window itself is when the plan actually gets tested against real conditions. Set up more frequent monitoring checks than you’d normally run during a quiet period, since a slow-building problem (a VPN pool approaching its session limit, a QoS queue dropping more than expected) is much easier to catch and correct early than after it’s caused a visible outage. If your team runs reduced staffing over the holidays, make sure whoever is on call actually has access to the dashboards and alerting that matter, not just a general on-call pager with no specific holiday-relevant context.
Common Mistakes in Holiday Network Planning
A few patterns show up repeatedly. Treating holiday traffic as simply “more of the same traffic, scaled up” instead of a genuinely different mix is the most common one. Skipping a test of your QoS classification rules against actual encrypted traffic, and only discovering the rule doesn’t match anything once the holiday surge has already started, is another. Skipping the rollback dry run that good holiday network traffic planning depends on, during a window when fewer staff are available to fix a mistake, is a third — and arguably the costliest, given the reduced support coverage most organizations run during the holidays.
Frequently Asked Questions
What’s the single most important part of holiday network traffic planning?
If one piece had to be prioritized above the rest, it would be a tested, reliable rollback process. A traffic surge you didn’t fully anticipate is survivable with good monitoring and quick manual intervention; a bad configuration change you can’t quickly reverse, made during a window with reduced staff coverage, tends to cause the longest and most painful outages.
How much extra bandwidth should I plan for during the holidays?
There’s no universal number — it depends heavily on your organization’s specific traffic mix and holiday remote-work policy. Reviewing your own prior-year flow data, where available, is a more reliable starting point than any generic industry rule of thumb.
Can my existing QoS policy handle holiday streaming traffic?
Only if it can actually classify encrypted streaming traffic correctly, which host-header-based matching alone cannot do. Test your classification method against real encrypted traffic before relying on it.
Does VPN usage go up or down during the holidays?
It depends entirely on your organization’s holiday remote-work policy. Check your own historical session data rather than assuming either direction.
Why do phishing attempts increase during the holiday season?
It’s a well-documented seasonal pattern across the security industry, generally attributed to a mix of distraction, higher expected volume of legitimate shipping/retail emails, and often-reduced IT support coverage during the period — all of which make social-engineering attempts more likely to succeed.
The Bottom Line
Holiday network planning is a genuinely distinct engineering problem, not just a capacity-scaling exercise. The traffic mix shifts in ways that break assumptions built into normal-week forecasting, QoS rules built for typical traffic may silently fail against encrypted streaming, and VPN and security posture both need deliberate, tested attention before the season starts rather than during it. Treating holiday network traffic planning as its own short seasonal project, with a tested rollback plan for any changes made, is what actually prevents the kind of surge-related failures this guide was written to help you avoid.
