Camera's of de NVR verliezen hun beeld

De recorder meldt dat een camera offline is en een minuut later is hij er weer. Of de live-beelden zijn prima en in de opname zitten gaten. Soms is het één camera, meestal de verste, soms zijn het er meerdere tegelijk en dan vaak op vaste momenten.

Wat het niet is: als álles in het netwerk tegelijk hapert, dan is dit niet je camerahoofdstuk maar een probleem met de bridge, een lus of de CPU van de router. Gaat het om één camera die nooit werkt, dan is het een instelling of de kabel, niet een netwerk dat verzadigd raakt.

De snelle controles, op volgorde

Krijgt de camera genoeg stroom? /interface ethernet poe monitor ether5 once. Je ziet daar de status, de spanning en het opgenomen vermogen. Een goed antwoord is een stabiele powered-on met een vermogen dat past bij de camera. Zie je overload, short-circuit of een waarde die op en neer springt, dan is dit je oorzaak.
Herstart de camera? Kijk of de poort telkens opnieuw linkt: /log print where topics~"interface". Link up en link down om de paar minuten op dezelfde poort is geen netwerkprobleem maar een voedingsprobleem.
Hoeveel verkeer gaat er echt doorheen? /interface monitor-traffic interface=ether5 op de poort naar de switch waar de camera's aan hangen. Acht camera's van 4 megapixel doen samen makkelijk 60 tot 100 Mbit/s, en dat moet allemaal door één uplink naar de recorder.
Worden er pakketten weggegooid? /interface ethernet print stats en kijk naar rx-drop en tx-drop, en naar fouten. Oplopende drops op de uplink naar de recorder betekenen dat de poort het niet bijhoudt.
Is het een MTU-probleem? Ping de camera met een groot pakket dat niet gefragmenteerd mag worden: /ping 192.168.20.31 size=1472 do-not-fragment. Kleine pings die werken en grote die verdwijnen, wijzen op een MTU die niet overal gelijk is. Dat geeft precies dit beeld: verbinding lijkt goed, beeld valt weg.
Is de topologie stabiel? /interface bridge port print en /log print where topics~"bridge". Een spanning tree die steeds opnieuw rekent, onderbreekt elke stream een paar seconden.

De gewone oorzaken, meest voorkomende eerst

PoE dat net niet genoeg is

Een camera aan het eind van zeventig meter dunne kabel krijgt minder spanning dan aan het begin. Overdag werkt hij, en 's nachts als de infraroodverlichting aangaat, schakelt hij uit en start opnieuw op. Dat is het klassieke "alleen 's nachts offline". Oplossingen: een dikkere kabel, een kortere route, een PoE-injector dichterbij, of de poort op forced-on als je zeker weet dat de camera dat aankan.

De uplink zit vol

Camera's uploaden constant en allemaal tegelijk. Hangt er een switch met acht camera's aan één gigabit-uplink, dan is er ruimte, maar aan een 100 Mbit-poort niet. Dit geeft geen nette foutmelding, het geeft weggegooide pakketten en dus gaten in de opname.

MTU die niet overal gelijk is

Zet je jumbo frames aan op één switch en niet op de volgende, dan verdwijnen grote pakketten zonder melding. Een pingtest werkt, de stream niet. Zet de MTU overal gelijk, of laat hem overal op 1500.

De camera en de recorder staan in verschillende VLANs

Een camera-VLAN is een goed idee, maar de recorder moet erbij kunnen. Staat het camera-VLAN op geïsoleerd, dan mag het alleen naar internet en juist niet naar je NVR.

Adressen die botsen

Camera's krijgen vaak een vast adres dat per ongeluk binnen de DHCP-range valt. Zodra de router datzelfde adres uitdeelt aan een telefoon, valt de camera weg en komt hij later terug.

Camera's op wifi

Een draadloze camera deelt lucht met alles wat er verder in de lucht zit, en een camera die continu uploadt is de slechtste denkbare wifi-client. Voor bewaking is een kabel geen luxe.

Wat de configurator hieraan doet

PoE-out per poort staat in het onderdeel Bridge & poorten, op modellen die PoE-out hebben, met de keuze auto-on, forced-on of off. Dat is de plek waar je een camera die niet opkomt geforceerd voeding geeft.
Teken je de bekabeling op het netwerkbord, dan vergelijkt de controle de MTU aan beide kanten van elke kabel en meldt een verschil met de exacte poorten erbij, inclusief de zin dat pakketten boven de kleinste waarde zonder foutmelding verdwijnen. Dezelfde controle kijkt ook naar de bridge-MTU van apparaten die met kabels aan elkaar zitten.
De controle noemt ook verschillende snelheden aan de twee kanten van een kabel, en zegt erbij op welke snelheid de kabel dan loopt. Zo zie je een 100 Mbit-poort in een pad dat gigabit had moeten zijn.
Zet je een camera als client-node op het bord met een VLAN en een vast IP-adres, dan controleert de tool of dat adres in het juiste netwerk valt, of het niet botst met een ander gepland adres, en of het niet in de DHCP-range ligt. Dat laatste is een opmerking met precies de zin die je nodig hebt: houd vaste adressen daarbuiten, anders kan de router hetzelfde adres uitdelen.
Draagt de switch waar de camera aan hangt het camera-VLAN niet, dan meldt de controle dat apart.
Een kabel die een lus maakt wordt gemeld, met de opmerking dat RSTP dan een pad blokkeert.
In het onderdeel QoS kun je met "Limieten per host/netwerk" het camera-netwerk een plafond geven, zodat een camera die op hol slaat de rest niet meesleept.

De eerlijke grens

De tool meet geen stroom en geen kabellengte. Of jouw PoE-budget klopt en of die kabel van zeventig meter nog genoeg spanning levert, blijkt alleen uit /interface ethernet poe monitor op het apparaat zelf. Ook de camera's tellen mee: firmware die vastloopt, een camera die zijn eigen tijd niet kan ophalen en daarom opnieuw start, of een NVR die de stream niet aankan, zien er in het netwerk hetzelfde uit als een netwerkprobleem. En een uplink die te smal is, blijft te smal: daar helpt geen instelling tegen, alleen een snellere poort of minder camera's op dat pad.

Verder lezen: Recept: camerabewaking, PoE-out en MTU.