How to Design a Surveillance Network That Doesn't Compete With Production Traffic
The wrong way to build a surveillance network is the way most are built: cameras sharing the same VLAN as the office printer fleet, recording NVRs talking to the same default gateway as the conference room VoIP phones, and a QoS policy that says "best effort" for everything because the previous integrator never set DSCP markings. The right way is engineered separation at three layers - physical or logical isolation, traffic-class marking, and bandwidth budgeting - so a 200-camera site never competes for uplink with the production environment that pays the bills. Here is the build sequence that survives day-two operations.
Step 1: Decide on Physical vs Logical Separation
The first design call is whether to run a separate switch fabric for cameras or to share switches with production via VLAN segmentation. Physical separation means dedicated switches, dedicated cabling, and a hardware boundary between camera and production traffic. Logical separation means shared switch hardware with 802.1Q VLAN tagging carrying camera traffic in its own broadcast domain over the same fiber and copper.
The trade is capex versus discipline. Physical separation adds 25 to 30 percent to switching capex (more chassis, more uplinks, more rack units) and removes any possibility of cross-traffic contention. Logical separation is cheaper but depends on every switch in the path being configured correctly and on the IT operations team understanding what a misconfiguration would do.
Use physical separation for sites over 150 cameras, for any deployment touching PCI, HIPAA, or controlled manufacturing networks, and for sites where the production network is run by a team other than the security integrator. Use logical separation for smaller deployments with a single network operations group. A 150-camera hospital that chose logical separation lost its nurse-call VoIP for 12 minutes when a misconfigured spanning-tree priority on a camera VLAN propagated a topology change into the production VLAN - the kind of failure that would have been physically impossible with a separate fabric.
Step 2: VLAN Strategy and Management Path
Even with physical separation, segment the camera fabric internally. A working reference layout uses four VLANs:
- VLAN 10 - camera streams (RTSP, ONVIF media)
- VLAN 20 - NVR / recording storage path
- VLAN 30 - camera management plane (web UI, ONVIF control, firmware push)
- VLAN 99 - network device management (switch, NVR appliance management)
Camera access ports live in VLAN 10. NVRs straddle VLAN 20 and 30 (recording on 20, control on 30). The trunk uplinks between switches carry all four VLANs tagged. The native VLAN is set to an unused number (such as 999) and never carries production traffic - this prevents native-VLAN hopping attacks where a malicious device on a misconfigured trunk port can speak to the native VLAN without a tag.
Inter-VLAN routing should happen at the firewall, not at the switch. Cameras need to reach the NVR and not much else. Routing camera-VLAN-to-management-VLAN through the firewall lets you enforce L4 ACLs that limit a compromised camera to ports 80, 443, and 554 toward the NVR - rather than letting it speak any protocol to anything on the management VLAN.
Step 3: QoS Marking and Honoring
QoS markings only matter if both ends of the path participate. The camera marks outgoing traffic at the source with an 802.1p PCP value (Layer 2) and a DSCP value (Layer 3). The switch trusts the marking on ingress and applies the matching queue policy on egress. Either end can break the chain.
The reference markings: DSCP AF31 (decimal 26) for camera video streams, DSCP CS6 (decimal 48) for management plane traffic, and DSCP EF (decimal 46) for VoIP if voice shares the path. The switch ingress trust mode must be set to "trust dscp" (or trust cos, depending on platform) - the default on most managed switches is "trust none," which dumps every packet into the default queue regardless of marking.
The egress scheduler should run strict priority on EF (voice goes first), weighted fair queuing on AF31 (video gets guaranteed bandwidth but does not starve other traffic), and best-effort on the default class. Per-port queue depth defaults to 64 KB on most platforms; raise to 256 KB on camera ports if the platform supports it, because video traffic bursts hard at GOP boundaries and the deeper queue smooths the spikes. A 300-camera school district that marked DSCP correctly at the camera but never enabled trust mode on the switches dropped roughly 4 percent of frames during the after-school traffic peak - the fix was a single switch-wide "qos trust dscp" command and a write-memory.
Step 4: Uplink Sizing
Aggregate camera bitrate sets the uplink budget. The working numbers per stream type:
- 1080p H.264 at 30 fps - 4 to 6 Mbps
- 1080p H.265 at 30 fps - 2 to 4 Mbps
- 4 MP H.265 at 30 fps - 4 to 6 Mbps
- 4K H.265 at 30 fps - 8 to 12 Mbps
Multiply by camera count, then apply a 3x burst factor for GOP-aligned spikes (most cameras send a full I-frame every 1 to 4 seconds, and the I-frames cluster at hour boundaries on synchronized NTP). Design the uplink for the burst, not the average. A 24-camera access switch running 1080p H.265 averages 72 Mbps but bursts to ~220 Mbps - a 1 Gbps uplink absorbs that comfortably; a 100 Mbps uplink drops frames.
For aggregation between access switches and the MDF, bond multiple uplinks with LACP (802.3ad) for both bandwidth and redundancy. Two 10 Gbps SFP+ links in a port-channel deliver 20 Gbps active-active and survive a single fiber cut without traffic loss. Target 70 percent utilization at peak as the design ceiling - higher than that and you have no headroom for camera-add work orders that always show up later.
Worked Example: A Mixed-Use Facility
An 84-camera deployment across a 4-story office, a 2-level parking deck, and an adjacent warehouse: 32 office cameras (mostly 1080p H.265 indoors), 18 deck cameras (4 MP H.265 with low-light), 34 warehouse and perimeter cameras (mix of 1080p H.265 and ten 4K H.265 for high-detail loading-dock work).
Aggregate average bitrate: 50 cameras at 2 Mbps + 25 cameras at 4 Mbps + 9 cameras at 10 Mbps = 290 Mbps. Burst factor of 3x = ~870 Mbps peak. This number drives uplink sizing all the way back to the NVR rack.
Layout: three IDFs (office, deck, warehouse) each with two 24-port PoE+ access switches and a 10 Gbps SFP+ uplink to the MDF. MDF runs two 48-port aggregation switches with 2x10 Gbps LACP to the NVR rack. Total port count: 6 access switches at 24 ports each (144) plus 2 aggregation switches at 48 ports each (96) = 240 ports, against an 84-camera load with 30 percent growth headroom. Recording stack: a server with redundant 10 GbE NICs aggregated to 20 Gbps, surveillance HDDs configured for sustained sequential write at over 200 MB/s aggregate. The PoE+ managed switches in the integrator-standard tier from the NETGEAR networking catalog (M4250 and M4350 AV-line series) fit this layout when paired with SFP+ uplinks - selection by feature match, not by brand-first habit.
Network Isolation Design Worksheet
Before any switch is racked, walk this 11-row worksheet. The single most common skipped row is "inter-VLAN gateway" - if the answer is "at the switch," go back and re-architect.
| Design question | Target answer |
|---|---|
| Separation model | Physical for over 150 cameras or regulated production; logical for smaller |
| Camera VLAN | Dedicated, no shared services, no internet egress |
| NVR VLAN | Dedicated, reachable from camera VLAN only via L4 ACL |
| Management VLAN | Separate from camera streams; admin access only |
| Inter-VLAN gateway | Firewall L3 interface, not switch L3 - enforces ACL |
| DSCP marking source | Camera marks at source: AF31 for video, CS6 for management |
| Switch ingress trust | Trust DSCP (or CoS) - default "trust none" breaks QoS |
| Egress scheduler | Strict priority for EF (voice), WFQ for AF31 (video), default for rest |
| Uplink sizing | Aggregate bitrate times 3 burst factor, 70 percent utilization target |
| 802.1X port security | EAP-TLS preferred; MAC auth bypass with strict ACL as fallback |
| Camera DNS / NTP | Internal only - cameras should not resolve public DNS or sync external NTP |
Step 5: Cybersecurity Boundary
Treat every camera as a compromise that has not happened yet. The design assumption is that one camera firmware will eventually have an unpatched RCE and that the attacker will use it as a pivot to whatever the camera can reach. Limit what the camera can reach.
The camera VLAN should have zero outbound internet egress - block at the firewall, log dropped packets, alert on more than a few drops per day per source. Camera-to-camera traffic is unnecessary in nearly every deployment and should be blocked with a switch ACL on the camera VLAN. Camera-to-NVR traffic should be limited to the specific TCP/UDP ports needed (typically 80/443 for HTTPS control, 554 for RTSP, 8000 or vendor-specific for the recording protocol).
802.1X with EAP-TLS adds machine-certificate authentication to the camera attachment - the switch will not enable a port for a camera that cannot present a valid certificate. On cameras that do not support EAP-TLS, fall back to MAC authentication bypass with a strict ACL: the port comes up in a quarantine VLAN until the MAC matches a known camera, then promotes to the camera VLAN. Bypass-only without ACL is barely better than no security - a swapped-in laptop with a spoofed MAC enters the camera VLAN unchallenged.
Deployment takeaway: A camera VLAN with zero internet egress, strict L4 ACLs to the NVR, and 802.1X attachment converts "compromised camera" from a network-wide incident into a single-port containment event.
Step 6: Day-Two Operations
The day-one design lives or dies in day-two operations. Three monitoring practices keep the deployment honest:
SNMP polling per port on the access switches captures throughput, error rate, and PoE draw per camera. Alert thresholds: per-port throughput over 80 percent of average for more than 5 minutes (probable camera bitrate misconfiguration), CRC errors over 0.01 percent of frames (cable or termination issue), PoE draw exceeding the switch's PSU budget at 80 percent (size up before a brownout takes the whole IDF).
Camera reboot rate is a quiet leading indicator. A camera that reboots once a week is showing thermal stress, PoE instability, or firmware crashes. Aggregate the reboot count per camera over 7 days; any camera over 3 reboots a week gets a manual inspection.
Firmware updates run on a separate change window from production network maintenance. Stage updates on one camera per model, observe for 72 hours, then roll to the fleet. Document the firmware version per camera so a regression can be backed out without guessing which camera is on which version. The infrastructure layout from the Infrastructure catalog tier supports SNMP, LLDP, and 802.1X across the same hardware family, which keeps day-two operations from fragmenting across multiple management consoles.
Where This Fits in a Deployment Program
Surveillance network isolation is the foundation layer for every other camera, intercom, and access-control deployment that runs over the same fabric. Get the separation, marking, and ACLs right at the network layer and most downstream issues simply do not occur. Get them wrong and every other layer above will spend years working around the foundation.
The catalog selection follows the architecture work. Once VLAN map, QoS marking plan, uplink sizing, and 802.1X policy are locked in, the switch short list narrows to a handful of models from all NETGEAR products (or equivalent vendors with the same managed-PoE feature set) - and the choice between them comes down to port count, uplink speed, and PoE budget, not on "which brand do we usually buy."
On Monday morning, log into one access switch carrying camera traffic. Pull the per-port DSCP marking distribution from the last 24 hours of SNMP data. If the bulk of camera traffic is showing DSCP 0 (best-effort), the QoS chain is broken at either the camera side (not marking) or the switch side (not trusting). The fix is one ingress trust command on the switch and one DSCP configuration push to the cameras. That single audit catches the most common "cameras are dropping frames" complaint without buying any new hardware - and it sets up the next month of work on the rest of the design worksheet.