Cameras or the NVR lose their stream

The recorder says a camera is offline and a minute later it is back. Or the live view is fine and the recording has holes in it. Sometimes it is one camera, usually the furthest one, sometimes several at once, and often at predictable moments.

What it is not: if everything on the network stutters at the same time, this is not your camera chapter but a bridge problem, a loop or the router's CPU. If one camera never works at all, it is a setting or the cable, not a network running out of room.

The quick checks, in order

1. Is the camera getting enough power? /interface ethernet poe monitor ether5 once shows the status, the voltage and the power drawn. A good answer is a steady powered-on at a wattage that matches the camera. overload, short-circuit or a figure that jumps around is your cause.
2. Is the camera rebooting? See whether the port keeps relinking: /log print where topics~"interface". Link up and link down every few minutes on the same port is not a network problem, it is a power problem.
3. How much traffic is really going through? /interface monitor-traffic interface=ether5 on the port towards the switch the cameras hang on. Eight 4-megapixel cameras easily add up to 60 to 100 Mbit/s, and all of it has to cross one uplink to the recorder.
4. Are packets being dropped? /interface ethernet print stats and look at rx-drop, tx-drop and the error counters. Rising drops on the uplink to the recorder mean the port cannot keep up.
5. Is this an MTU problem? Ping the camera with a large packet that may not be fragmented: /ping 192.168.20.31 size=1472 do-not-fragment. Small pings that work and large ones that vanish point at an MTU that is not the same everywhere. That produces exactly this picture: the connection looks fine, the image drops.
6. Is the topology stable? /interface bridge port print and /log print where topics~"bridge". A spanning tree that keeps recalculating interrupts every stream for a few seconds.

The usual causes, most common first

PoE that is just not enough

A camera at the end of seventy metres of thin cable gets less voltage than one at the start. It works during the day, and at night when the infrared illuminator comes on it shuts down and restarts. That is the classic "only offline at night". Fixes: a thicker cable, a shorter run, a PoE injector closer by, or setting the port to forced-on when you are certain the camera can take it.

The uplink is full

Cameras upload constantly and all at once. A switch with eight cameras on one gigabit uplink has room; on a 100 Mbit port it does not. This produces no tidy error message, it produces dropped packets and therefore gaps in the recording.

An MTU that is not the same everywhere

Turn jumbo frames on for one switch and not the next and large packets disappear without a word. A ping test works, the stream does not. Make the MTU equal everywhere, or leave it at 1500 everywhere.

The camera and the recorder are in different VLANs

A camera VLAN is a good idea, but the recorder has to be able to reach it. Mark the camera VLAN as isolated and it may talk to the internet and specifically not to your NVR.

Clashing addresses

Cameras often get a fixed address that happens to sit inside the DHCP range. The moment the router hands that same address to a phone, the camera drops out and comes back later.

Cameras on Wi-Fi

A wireless camera shares the air with everything else in it, and a camera that uploads continuously is the worst Wi-Fi client imaginable. For surveillance, a cable is not a luxury.

What the configurator does about it

• PoE-out per port is in the Bridge & ports section on models with PoE-out, with auto-on, forced-on or off. That is where you force power to a camera that will not come up.
• Draw the cabling on the network board and the check compares the MTU at both ends of every cable, reporting a difference with the exact ports and the sentence that packets above the smaller value are dropped without an error. The same check looks at the bridge MTU of devices joined by cables.
• The check also reports different speeds at the two ends of a cable and says what speed the cable then runs at. That is how a 100 Mbit port shows up in a path that was meant to be gigabit.
• Put a camera on the board as a client node with a VLAN and a fixed address and the tool checks that the address is inside the right network, does not clash, and is not inside the DHCP range. That last one comes with the sentence you need: keep fixed addresses outside it, or the router may hand out the same address.
• If the switch the camera is cabled to does not carry the camera VLAN, the check says so separately.
• A cable that closes a loop is reported, with the note that RSTP then blocks one of the paths.
• In the QoS section, "Limits per host/network" lets you cap the camera network so that one camera running away does not take the rest with it.

The honest limits

The tool measures no power and no cable length. Whether your PoE budget adds up and whether that seventy metre run still delivers enough voltage can only be answered by /interface ethernet poe monitor on the hardware. The cameras count too: firmware that hangs, or an NVR that cannot keep up with the stream, looks exactly like a network fault from the network's side. And an uplink that is too narrow stays too narrow: no setting fixes that, only a faster port or fewer cameras on that path.

Read on: Recipe: camera surveillance, PoE-out and MTU.