Connecting a PoE switch to an NVR means three decisions in order: which of the three wiring topologies you use, whether the cameras share a subnet with the recorder, and how much uplink bandwidth the recorder's link actually carries. Get those right and the rest is patching, VLAN assignment and adding cameras.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Topology one, an external PoE switch under the NVR, scales best. Topology two, the NVR's built-in PoE ports, is fine up to the port count and power budget printed on the recorder. Topology three, dual network ports, is the one to use when cameras must not reach the corporate LAN.
Put cameras in their own VLAN with port isolation, and remember that ONVIF discovery uses link-local multicast. If the recorder sits in a different subnet, discovery stops working and cameras must be added by IP address.
A stuttering picture is rarely a bandwidth problem on the switch uplink. Work the order: uplink utilisation, then broadcast and multicast, then camera bitrate adaptation, then PoE power cycling.
Everything below is how to connect PoE switch to NVR in practice: the wiring, the switch configuration and the order in which to do them.
Pick the topology before you buy anything, because it fixes the port count, the power budget and the IP plan. A poe switch for video surveillance sits in front of the recorder in two of the three options below, and in the third it carries every camera while the recorder only listens.
| Option 1: external PoE switch under the NVR | Option 2: NVR built-in PoE ports | Option 3: dual network ports on the NVR | |
|---|---|---|---|
| Wiring | Cameras to the switch; one uplink from switch to the NVR LAN port | Cameras directly into the recorder's PoE ports | NIC 1 to the camera switch, NIC 2 to the corporate or uplink network |
| Where PoE comes from | The switch | The recorder's internal supply | The switch |
| Port limit | Switch port count, typically 8 to 24 | The recorder's port count, commonly 4, 8 or 16 | Switch port count |
| Power limit | The switch's PoE budget, which you can size | Whatever the recorder's internal supply allows, often 40 to 80 W total | The switch's PoE budget |
| Camera isolation | Full VLAN and port isolation available | Usually a fixed internal switch with limited or no VLAN control | Full control on the camera side |
| Best for | Eight cameras and up, long cable runs, outdoor enclosures | Small sites where the recorder and cameras are in one cabinet | Sites that must keep cameras off the office network |
| Main weakness | One more device to power and configure | Out of ports and out of watts at the same time | Two default gateways are a classic misconfiguration |
This is the topology most sites end up with, and it has one real choice inside it: same subnet or different subnet.
| Same subnet (Layer 2) | Different subnet (Layer 3) | |
|---|---|---|
| Addressing | Recorder and cameras in one IP range, for example 192.168.10.0/24 | Cameras in 192.168.10.0/24, recorder's camera-side NIC in 192.168.20.0/24 |
| ONVIF discovery | Works, because the discovery multicast stays in the broadcast domain | Does not cross the router; add cameras by IP address manually |
| Broadcast domain | Cameras, recorder and any client on the same VLAN share it | Camera floods are contained in the camera subnet |
| Configuration effort | Lowest | Needs a gateway, a route and manual camera entry |
| Typical use | Single cabinet, fewer than 16 cameras | Camera count above 16, or a security policy that requires separation |
The ONVIF point catches people out. Camera discovery uses WS-Discovery, a link-local multicast on UDP port 3702 addressed to 239.255.255.250 with a TTL that does not survive a router. Move the recorder to another subnet and the auto-discovery list comes back empty, which looks like a broken switch and is actually correct behaviour.
The wiring sequence, in the order that avoids rework:
Rack and power the switch first. Earth it, confirm the input voltage is within the range on the label, and log in before any camera is patched.
Patch cameras into the PoE ports and watch the PoE LED. A port that links but does not power up is a cable or a class problem, not a configuration problem.
Create the surveillance VLAN and assign every camera port to it as an untagged access port.
Enable port isolation on the camera ports so cameras cannot reach each other, only the uplink.
Configure the uplink port as a trunk carrying the surveillance VLAN if the recorder is elsewhere, or as a plain access port in the same VLAN if it shares the subnet.
Set the recorder's camera-side address, then add cameras, by discovery in the same-subnet case and by IP address in the routed case.
Set resolution, frame rate and bitrate per camera, then start the recording schedule.
Save and back up the switch configuration before the cabinet door closes.
For a small site this is the cheapest correct answer: a typical 8-channel recorder with eight PoE ports on the back takes eight cameras, powers them, and records them, with no switch to configure.
The limits are physical and they arrive together. Port count is fixed, so camera nine needs a switch anyway. Power is shared across all ports from one internal supply, so eight cameras with IR heaters at dusk can exceed what the recorder provides even when each camera is individually within its class. And the built-in switch is usually unmanaged, which means no VLAN, no port isolation and no per-port power priority.
Use it when the camera count fits with at least two spare ports, the total draw stays under about 80% of the recorder's stated PoE budget, and there is no requirement to separate camera traffic from anything else.
Recorders with two network interfaces let you keep the camera network physically and logically separate from everything else. NIC 1 faces the camera switch; NIC 2 faces the office LAN or the internet gateway.
The one rule that prevents most failures: configure a default gateway on only one interface, the one facing the internet or the corporate network. On the camera-side interface, configure the IP address and subnet mask only, and add a static route for the camera subnet if the recorder needs one. Two default gateways on one host produce an ambiguous routing table, and the symptom is remote viewing that works for a while and then stops.
With that in place, clients on the corporate LAN reach the recorder through NIC 2, camera streams never leave NIC 1's subnet, and a camera compromised on the surveillance VLAN has no route to the office.
Three VLANs cover most sites, and the point of all three is to make camera traffic stay where it belongs.
| VLAN | Members | Uplink treatment | Why it exists |
|---|---|---|---|
| Surveillance | All camera ports, plus the recorder's camera-side port | Trunked to the recorder | Contains camera floods and keeps camera traffic off the office LAN |
| Management | Switch management address, NMS, engineering laptop | Trunked, and rate-limited at the port | Lets you reach the switch without exposing it to cameras |
| Client access (optional) | Workstations that view live and playback | Routed to the recorder's second interface, never bridged to the surveillance VLAN | Viewers reach the recorder, not the cameras |
Two settings matter beyond the VLAN assignment itself. Port isolation on the camera ports stops a compromised camera from reaching its neighbours, and it also removes the camera-to-camera traffic that otherwise fills the uplink. Storm control on the same ports caps broadcast and multicast at a small percentage of link rate, which is the single most effective protection against a camera with a fault flooding the segment.
Do the arithmetic per camera and then add overhead, rather than guessing from the port speed. On a poe switch for ip cameras the uplink is usually a non-PoE gigabit port, so all eight camera streams plus client traffic converge on that one link.
Eight cameras at 4 Mbps each is 32 Mbps of stream. Ethernet framing, interframe gaps and retransmissions add roughly 20%, so plan for about 38 Mbps. Add a live-view stream from the recorder to each client workstation: three operators watching a 4 Mbps stream each is another 12 Mbps. Playback reads from disk come out of the same interface as well, so during an incident review the recorder's port can be carrying well over 50 Mbps.
That is still a small fraction of a gigabit link, which is the useful insight: if the picture stutters, the uplink is almost never saturated at the switch. What saturates is the recorder's own network interface, because inbound camera streams, outbound client streams and playback reads all cross the same port when only one interface is wired.
Leave MTU at 1500 unless every device in the path supports the larger frame: camera, switch port, uplink, recorder, and any router in between. IEEE 802.3 fixes the standard Ethernet frame at 1518 bytes including the CRC, or 1522 bytes once an 802.1Q tag is added, and anything larger — usually 9000 bytes — is a vendor convention rather than a standard, which is exactly why support varies from box to box. A jumbo frame arriving at a 1500 byte interface is either fragmented or dropped, and the failure is intermittent, which makes it expensive to diagnose. The throughput gain on a 4 Mbps camera stream is negligible anyway, so the trade is a theoretical improvement for a real risk.
Work from the link inward. Each step eliminates a whole class of cause.
Check uplink port utilisation on the switch. If the uplink to the recorder is below about 50% of link rate during the stutter, bandwidth is not the problem and you move on.
Check broadcast and multicast rates. A camera flooding the segment will peg the recorder's CPU and the switch's CPU long before it fills a gigabit pipe. Storm control counters and port isolation tell you within a minute.
Check whether the cameras have dropped their own bitrate. Many cameras reduce frame rate or resolution when their own uplink is congested or when the recorder cannot keep up. Compare the configured stream profile in the camera with what the recorder reports receiving.
Check PoE per port draw and uptime. A camera that reboots every few minutes is usually losing power, not network. Look at per-port power and port uptime counters, especially at dusk, when IR illuminators and heaters switch on across every camera at once. IEEE 802.3af caps a PSE port at 15.4 W and guarantees about 12.95 W at the powered device, and IEEE 802.3at raises those numbers to 30 W and about 25.5 W, so a camera idling at 6 W that draws 11 W with its heater on is still inside a Class 3 budget — until eight of them share one recorder with a 40 W internal supply, which is where the dusk reboots come from.
If all four come back clean, the problem is on the recorder: disk throughput, decode capacity, or client-side rendering.
Can cameras and the NVR be on different subnets?
Yes, but the recorder will stop discovering them automatically. ONVIF discovery uses a link-local multicast that does not cross a router, so in a routed design you add each camera by IP address instead of picking it from a discovery list.
Why does my NVR stutter when only one network port is connected?
Because camera streams inbound, client live view and playback reads outbound all cross that single interface, so the recorder's own NIC becomes the bottleneck long before the switch uplink is full. A second interface, with the default gateway configured on only one of them, separates the two directions.
Do I need a separate VLAN for cameras?
Almost always. A surveillance VLAN with port isolation contains camera broadcast traffic, stops cameras from reaching each other, and keeps camera floods away from the office LAN. Storm control on the same ports is the companion setting.
How much bandwidth do eight 4 Mbps cameras need on the uplink?
About 32 Mbps of stream plus roughly 20% for framing and overhead, so plan for around 38 Mbps, plus any live view and playback traffic to clients. That leaves a great deal of room on a gigabit uplink, which is why stutter is rarely a raw bandwidth problem.
Should jumbo frames be turned on for video traffic?
Not by default. Every device in the path must support the larger MTU, and a mismatch produces intermittent drops that are hard to trace. The throughput gain on a 4 Mbps camera stream does not justify the risk.
Wire the topology first, then the VLAN, then the addresses, then the cameras: that order prevents the two failures that cost the most time, an ambiguous default gateway and a discovery list that is empty because the recorder moved subnets. Rayin builds the 8+4-port gigabit industrial switch line with PoE options for this exact job, with VLAN, port isolation and storm control available on the managed models, and the configuration steps above apply to any managed switch on a poe switch for video surveillance.
Choosing a PoE Switch for IP Cameras: Power and Bandwidth Together
PoE Distance and Cable: Choosing the Run That Still Delivers Power
The specifications, thresholds and standard references quoted above come from public industry sources — the IEEE 802.3af and 802.3at power classes, IEEE 802.3 frame-size limits, and published vendor datasheets — rather than from marketing copy. The method, worked examples and wording are written by Sara, who checked each figure against those sources before publication. Anything presented as an industry-typical value is labelled as such; nothing here is a measured figure from a Rayin product unless it says so.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
