Subscriber Discussion

Cameras Unreachable From Milestone Server, Why?

UI
Undisclosed Integrator #1
Jun 02, 2017

I have a customer that is running Milestone 2014 Professional.  The system is comprised of 4 buildings.  1 Server per building and it is running in a master slave environment.  OS is Windows 7 Professional.  The issue that I am having is at random a camera will no longer respond to pings from the server.  If I login to the switch I can ping the camera fine.  If I plug my laptop into the switch I can ping the camera just fine.  Disabling and re-enabling the NIC sometimes works.  Also sometimes a reboot of the server will also sometimes fix the issue.  Each server is running on its own subnet through 1 NIC on each server.  The other NIC on all of the servers goes to the customers LAN.  I have never seen anything like this happen before and I am at a loss right now.  Any all help is very much appreciated.

JB
Josh Bylsma
Jun 02, 2017
BLUEmark Technologies

Your variable is the customers LAN. Just because you can ping cameras/servers does not mean everything is communicating. 

Suggestions:

- Check to see if you are traversing any DMZs, firewalls or routers

- Check for any LAN restrictions the customer has (blocking activeX, unsecured certificates, etc.) 

- Check blocked ports

- Have the customer create port rules, specific to the ports needed 

- Check PoE settings, if using PoE switches, ensure power draw is enough

- Check QoS setting on customer switches

These are where I would start... to be honest, it could be a great number of things. Start here for now. I am sure others will have other ideas as well. 

(With I could recoup the lost years of my life trouble shooting IT issues on customers LANs)

Avatar
Ethan Ace
Jun 02, 2017

So when you say you can't ping them from the server, does that mean that the video stream is going down as well? I'm trying to understand the full issue here.

Like Josh says, the customer LAN may be an issue. I've seen cameras work fine but not be pingable, and some pingable but not stream. It all depends on how things are/are not firewalled.

U
Undisclosed
Jun 02, 2017

I concur with the posted advice.  Sounds to me like a routing issue.  Adding to previous suggestions...  check subnet masks (255.255.255.0 is not the same as 255.255.0.0...); do traceroute from the server to the camera and make sure it responds as expected; since you say you can log into the switch check it's logs for any anomalies (like a link up/down event indicating the camera lost power but you didn't notice.)

 

Avatar
Josh Hendricks
Jun 03, 2017
Milestone Systems

I have seen strange situations where the ARP entry for a camera is on the wrong NIC. I'm not sure if I've ever tracked down how this happens, but I suspect it comes down to VLAN configuration issues or the switch doing something funny with proxy arp.

Basically ARP is a protocol for allowing TCP/IP hosts to broadcast a question on the network like "Who has IP 1.1.1.1? Tell me at IP 2.2.2.2", and whoever has that IP address should respond with their MAC address. Your computer then caches this information for a while.

On systems with multiple NICs, I have seen network configuration issues (either duplicate IP's, multiple gateway situations etc) result in the IP of a camera showing up in the ARP cache under the wrong NIC.

I recently saw this happen at a site where the cameras were losing their IP's for some reason and broadcasting their APIPA address (169.x.x.x).

If cycling the NIC temporarily fixes it, it's probably because the arp cache is getting reset.

You can check the state of the arp table by running arp -a from the command prompt. Try looking through the result for both the IP and the MAC of the affected camera(s) to see if anything stands out.

UI
Undisclosed Integrator #2
Jun 03, 2017

I didn't read all of the responses but what about bitrate?  Maybe adjusting camera recordings to allow for consistent bitrate?

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions