Panorama Log Retention and Commit Time for 26 Firewalls
A Panorama virtual appliance manages 26 firewalls (PA-3220 and PA-5220) for a manufacturer. Traffic logs average 60 GB/day, and TLS decryption is about to be enabled on roughly 40% of traffic. Compliance requires traffic logs for 90 days and threat logs for one year, with ad hoc searches over the last 30 days returning in under 30 seconds. Today all firewalls forward to Panorama's local disk, which fills every nine days, and a push to devices takes 12 minutes. A single 200 Mbps WAN link connects each site to the data center where Panorama lives. The team has no budget for a second data center, and the audit window starts in six weeks.
1. Do the storage and search requirements fit on Panorama's local disk? Size it and pick an architecture.
Read the worked answer
Sizing (state assumptions explicitly):
- 60 GB/day traffic plus roughly 25-30% from decryption (extra sessions and decryption summary logs) gives about 78 GB/day. 90 days is about 7 TB.
- Threat logs at even 0.5 GB/day over a year is about 180 GB.
- Add 20-30% headroom so you never hit a full-disk condition and so indexes have room: ~9 TB usable.
- RAID-1/RAID-10 roughly doubles raw requirement: ~18 TB raw.
Answer: it does not fit. Panorama's local disk is fixed by the VM disk size, cannot be grown online without risk, and is the same management plane that must serve 26 device commits and log queries - filling it every nine days is the symptom.
Architecture: Panorama in Panorama mode with dedicated log collectors in a collector group, each sized so a single collector loss does not destroy the retention window, and firewalls distributed across collectors. If the Cortex Data Lake subscription is available, that removes the storage sizing problem and gives cross-firewall search plus one-year threat retention - check licensing per managed firewall before promising it.
The 30-second search target is a query fan-out problem as much as a disk problem: 26 firewalls hammering one collector will miss it, so spread devices across collectors and keep the 200 Mbps WAN in mind for log forwarding backfill.
2. Why does a push to devices take 12 minutes, and what would you change structurally?
Read the worked answer
- Time scales with devices in the device group and total config size. One device group containing all 26 firewalls means the same rulebase is recalculated and validated 26 times per push, and HA pairs are updated member by member.
- Restructure: device groups by policy function or region (edge, DC, branch) with shared policy in pre-rules; templates and template stacks with variables for site-specific addressing instead of 26 near-copies; prune unused and orphaned objects, and de-duplicate objects so pushes stop carrying duplicates.
- Replace giant static groups with EDLs / dynamic address groups so a rulebase change no longer requires a full object-tree push.
- Operational levers: validate before commit (
validateand a test push to a lab pair), schedule pushes into a maintenance window rather than mid-day, use commit scoping/partial push if the Panorama version supports it, and never push while the management plane is busy serving log queries. - Track the result: the metric is delta config per push, so the goal is small, frequent, scoped pushes rather than one weekly monster.
3. Cut forwarded log volume by half without losing the audit evidence.
Read the worked answer
- Tier the retention. Forward to the collector the traffic that compliance actually needs - internet egress and denied sessions - and keep intra-zone and trusted-to-trusted traffic on-device with a short on-box retention. This is the single biggest saving and it is defensible in an audit if documented.
- Turn off session logging on rules that do not need it (intra-zone allows, the internal backup and monitoring segments) and confirm you are not logging at both start and end where end alone suffices.
- Forwarding-profile filters: forward threat, WildFire, URL and data logs unconditionally; for traffic logs use a filter that excludes a known list of high-volume, low-value applications (backup, patching, monitoring) and keep allowed-URL logging limited to blocked and high-risk categories.
- Do not use log suppression as a substitute for retention - it reduces volume but can also remove the individual records audit asks for.
- Re-measure after one week against the 60 GB/day baseline and confirm both the 90-day traffic and one-year threat windows still fit the sizing from the first task.