Dual NIC Cameras?

I have an application that would benefit greatly from having cameras with two Ethernet ports. The Camera Finder tool doesn't have that as a sorting option, and off-hand I'm not aware of any cameras that have dual NICs. Can anyone point me toward a brand or line that does?

So you actually would benefit from two physical rj-45 jacks? Or do you just need two seperate IP addresses?

Would they both stream video?

The ideal in this application is to dual-route the video stream over two physically separate networks (switches). This is an extremely critical application (obviously) that demands maximum uptime. Any loss of video requires dispatching security, and the driving distances involved are significant, so loss of video comes with large penalties.

One obvious alternatives to dual NICs is multiple cameras with overlapping views. However, the cost of a NIC is extremely low, I've heard figures well under $1/NIC. Installing multiple cameras with overlapping views, is not nearly as inexpensive, and through critical this application does have cost limitations.

Having two separate IP addresses on one RJ jack doesn't allow for dual routing the stream over two separate networks, at least as far as I know. I had asked about the possibility of some kind of a passive splitter (aka a tap as used in network monitoring) to get two streams from a single two-IP address camera. but that was a bit of a shot in the dark as I don't even know of such a commercially available device, and neither did my very knowledgeable Cisco rep.

As an aside, the Camera Finder tool doesn't seem to identify dual IP address cameras either.

Any suggestions greatly appreciated.

The Camera Finder doesn't identify dual NIC/dual IP address cameras because if they exist at all, they're an extremely rare use case. The only dual-NIC cameras I know are the Vivotek daisy chain models, and that is, I believe, one IP address. The multiple ports are for extending PoE to the next camera. I'm not sure that would help in this application.

Oh, I do understand that Ethan, though I'm not sure I understand why they're such a rare bird. If the manufacturing cost of a NIC chipset is as low as I was quoted, there would seem to be some value in having the option of dual-routing video. As you said, it would still be a niche market, but a low-cost differentiator such as this seems to have some potential value to a manufacturer.

Thanks for the lead, I'll follow up with them.

If anyone else knows of another source please pass it along.

Oh to be sure, the NIC itself is likely a matter of cents, not dollars. But the development work to implement dual NICs, multiple IP addresses, various and assorted modes (failover, full time streaming, etc.), and all that is likely more money than the return on investment for implementing it. I'm sure it's been considered at one point or another! But I've quick checked a couple of more niche manufacturers and seen nothing.

The pure hardware cost of the PHY is likely not that much. It would take up extra board space though, and require additional software development, and would make the pigtails more expensive.

IMO, this isn't a rare thing because of cost, but because of demand. In the very very rare cases where I've spoken to a customer with a need similar to what you describe, they want everything redundant, including the camera itself. Given all the stuff that can go wrong inside the camera, it seems like it would be a bit shortsighted to duplicate everything except for a $400 camera.

There is also the Stardot multi-channel long distance "self healing" token-ring-like topology. However, I don't know if you want to go down such a proprietary route.

In this situation, the sensors and cameras will be set up in clusters. Each cluster will have a PTZ, so the loss of a single camera won't by itself trigger a dispatch, but the loss of multiple cameras in a cluster would require a dispatch.

We're talking about a lot of cameras at each location, and a lot of locations, so that $400 camera becomes quite an expensive add-on.

I'm not familiar with the Stardot line, I'll follow up on that. Thanks.

Yeah, I think the number I heard was less than 50cents. But you're probably right, it seems unrealistic that number included the other aspects needed to actually use the second NIC.

Ah, it seemed like a 'too good to be likely' long shot. I hate it when I'm right.

What about having the SD card in the camera? NIC or systems goes down, no problem camera is still recording, NIC comes back it dumps to the server of your choice.

So the key issue we're trying to avoid is dispatching security (and other) personnel, which we have to do if the SOC looses a live feed (regulatory requirement). There are dozens of sites scattered across California, and it can take serious windshield time to get to them, so every live video failure is expensive and time consuming. An SD card backup is good as a backup but doesn't avoid the need to dispatch.

I'm going to call Vivotek and see it their daisy chain cameras allow for two IP addresses, since that seems to be the only possible solution so far.

I'm going to call Vivotek and see it their daisy chain cameras allow for two IP addresses, since that seems to be the only possible solution so far.

Daisy-chaining and redundancy typically don't go together.

Many cameras have two NIC's; in the form of a wired and wireless interface. I haven't played around with any to see if you can ever have them both active at the same time though.

Theoretically there's no reason they couldn't be, though you might need an embedded Linux guy to get it working.

Why are you so adamant on 2 nics? If a nic failure is what you're worried about chances are greater that the camera will fail too. If they're going to be installed in clusters then why don't you just have them plugged into a switch and set port mirroring to a separate Vlan and then use a commercial router to route out via two separate links? Or you can use the same commercial router to do the dual routing for you.

So one of the criteria that I'm having to work around is the that, though the camera is obviously a single point of failure, the customer is insistent that all parts of the network be redundant. Given this, using a single switch at the camera is what they are trying to avoid.

Their initial idea was to install Omnitron media converters at the cluster, which create a redundant network path immediately after the camera. I don't like this because a) it means each RJ port will be cable separately (and x2) back to the network hub (massive cabling issue), and the network team will have no visibility past the network hub (all they will be able to say is "No idea why your cluster went down, it all looks good from here.")

Does having redundancy of the network make sense when the cameras are not? I build to customer requirements, so as long as they're not fundamentally flawed, I withhold judgement. :)

Just an idea but what you could do is get a camera that has a analog output and have that run to an encoder on a separate network.

Not a bad idea, but if you're going to have to run coax and power to the camera, include a couple hundred dollar encoder and (if necessary) licensing I don't think the cost differential is much more than just adding another camera... unless they are PTZs.

...but if you're going to have to run coax and power to the camera...

Actually, in most IP cameras with full time analog output I know about, no auxiliary power is needed. You can still run it on POE only. (I'm not sure if it would satisfy redundancy requirement)

And some single channel encoders are less than $70

I have to say, I really like this approach. It meets the customer's original design goal of a fully redundant network. And since they were planning on having the Omnitron fiber drivers at each cluster anyway, having an encoder doesn't really add an extra (potential failure) devices over their original proposal.

We would end up with one NIC/IP directly from the camera, and another set from the encoder. The only single point of failure would be the camera itself, which they were willing to accept from day one. I could route the two NICs to two different switches, so the loss of a single switch (whether due to maintenance or unplanned) would have no affect. And of course each switch could be on a separate (diverse) physical route back to the network hub for full network diversity. (Each hub on each site is also connected by multiple and diverse physical routes back to the SOC, so the entire network is very robust.)

Brilliant! I've put this out to the client to see how they feel about it. I don't have time to check the camera finder right now, does it allow for searching on cameras with both analog and IP outputs? I hope these are readily available...

Kudos to U3!

One slight downside, the redundant encoded stream will be only SD resolution.

Fair point, I'll make sure they understand that limitation. It will be interesting to see their response to the idea.

You might also mention that any PTZ's might not be controllable, since you would need cameras and encoders with rs-485 ports as well as a way to failover from IP control.

Many of the GeoVision cameras have analog video as well as the IP output available. Just remember the analog output is going to be a 640x480 output, nothing megapixel. I use them when I need to feed an existing analog switcher system while still recording a megapixel stream. Be sure to look at each spec - some do, some don't.

Currently testing a Hikvision DS-2CD2742FWD-IZS which has analog and IP outputs. You won't find it mentioned on any of Hikvision's spec sheets though, so once it arrived I was pleasantly surprised to see a BNC hanging off the whip as well.

I probably would have eventually realized that, lol.

Many thanks to all for helping come up with ideas. It's now in the customer's hands, and it's anybody's guess what the final outcome will be, but I'm getting the impression it will be sooner not later.

What remains to be seen is whether I'll be able to get them to slow down long enough to do a test install to make sure they like it - in my company it's often 'build to the schedule' even if we don't know whether it will work right. Seems there's always time (and money) to do things over...

Ok, now that you've made your official recommendation, I would like to make a suggestion that is so bizzare that even if there were no obvious technical problems, I doubt it would be worth the risk.

Still I would like to know if anyone can say out of hand what would fail with the following fanciful solution:

First you would get one one of those Vivotek daisy-chain cameras that Ethan remembered. They are basically a camera with two rj-45's and a built-in two port switch.

The idea would be to get one of the rj-45 ports to the existing switch and the other one to the (new?) redundant switch.

Since you said cabling another run back to a redundant switch would be a massive amount of work, you could run both on one cable by using 1,2,3,6 for one port and 4,5,7,8 for the other and then using custom crimps at both sides to split back to two.

Next you would setup the Vivotek to send the stream as multicast. Because the built in two port switch is unmanaged it would end up sending out the multicast on both, because it doesn't know any IGMP info and so therefore must broadcast it.

Then you would setup on the managed switches STP, spanning tree protocol, to prevent a possible multicast storm at the point when the primary and the redundant networks converge.

Which would make the redundant switch drop the multicast. However if the primary network were to fail, STP would enable the forwarding of the multicast by the redundant switch, since it would not cause a loop.

Yeah, weird. But what part would definitely not work?

For info Mobotix cameras allow two IP addresses and different ports

In single imager cameras?

If you are concern about image availability then you should install two cameras (probably cheaper than dispatching staff in case of failure) on two different network and switch looking at the same thing. Way cheaper than trying to hack something special that's hard to maintain in the long run. Just make sure to put a UPS on that system to ensure maximum availability of the video feed.