Networking thoughts with NVR server...

[jasauders]

Hi friends. I'm trying to wrap my brain around whether or not this will work in the way I'd like it to. I'm currently running 6 cameras and a 24 port gig switch, but all cameras are on POE injectors. It was a free option at the time as I already had them, so I ran with it temporarily. Being shipped to me is an 8 port gig POE switch.

I'm running an Ubuntu Server with Bluecherry. By adding the POE switch, I would have the cameras somewhat segregated from the main LAN. What I'm wondering is if I can add a 2nd NIC to the server, IP is on the same subnet but different IP, and tap that into the POE switch.

So you figure...

Modem >> Router >> 24p LAN switch
24p LAN switch >> server NIC A @ 192.168.1.20
24p LAN switch >> 8p POE switch >> server NIC B @ 192.168.1.21

That would in effect give the server a direct connection to each switch. My question is... during your typical day my camera bandwidth should not hit the 24p switch (correct?), as the cameras will come in to the 8p POE, see the connection to the server on NIC B @ 192.168.1.21, and continue their 24/7 recording... OR will they somehow know they need to go to the IP of 192.168.1.20 and pull the bandwidth feed up to the 24p LAN switch and back down through NIC A (.20)?

From my understanding/the process I went through to set the cameras up with Bluecherry, Bluecherry effectively pulls the feeds in, so Bluecherry is looking for ip.of.camera.one, ip.of.camera.two, ip.of.camera.three, etc. I would assume it would take the path of least resistance, and such, not let the typical 24/7 recordings deviate up to the 24p LAN switch.

My other thinking is I need to point the Bluecherry client to a specific IP of the server. Currently it points to 192.168.1.20 as that's my only NIC. Works great, no issues, etc. If I add another NIC, I wonder what route I should be going. Would I be able to keep the clients pointed to NIC A @ 192.168.1.20? I'm sure at that point it would be routing the Bluecherry traffic for live feeds, event playback, etc. up to the 24p LAN switch and back down to whichever client computer I am using (which is not an issue, I'm just looking to keep the camera bandwidth on its own separate switch during the recording process when I am not connected to the Bluecherry client, which is 99% of the time). Though at the same token I could probably point it to NIC B @ 192.168.1.21 and have more of a direct connection effect. That may be the answer, but it makes me curious if I could still point clients to NIC A @ 192.168.1.20 (as I currently do) and see it still function without issue.

 

[nayr]

dont hook your 24p LAN switch to your 8p POE switch at all.. make the only bridge between the two your dual homed Ubuntu Box, run a proxy server on it if you need web access to the cameras and a ntp server so it can keep your camera's time's synced with the internet.

your 8p poe network needs to be another subnet, so like 192.168.2.20 with mask of 255.255.255.0 and no gateway.

 

[jasauders]

Thanks for your response. I'm so infrequently in my camera Web interfaces that I could just hard wire my other laptop to the 8p poe for that rare occasion. The only lingering question is the Bluecherry client. The client is what pulls in live steams, event browser, etc. If I proxy the two server network cards with both on different subnets, could I still point my Bluecherry client on any client system on the 24p switch lan to 192.168.1.20 nic A and it pull in the 8p camera traffic on the poe switch?

 

[nayr]

no idea on bluecherry specifically, but the NVR is supposed to provide the streams to the clients directly.. not the cameras.. so as long as you can connect to the NVR, it should basically proxy the video streams from the cameras on its own.. either raw or transcoded.. basically the NVR should be able to provide streams for all its cameras so as long as you can connect to it with the app... at least thats how its supposed to work.

if thats not how bluecherry works, no big deal.. we'll just turn that ubuntu box into a router and have it handle traffic going between subnets.. as long as your main router can be configured for some static routes.

 

[jasauders]

Thanks for the insight, nayr. I assume Bluecherry works in a similar sense as most other NVRs. Bluecherry "pulls" the streams from the cameras, and thereby provides a "live stream" of all cameras within its own interface.

It gets a little confusing trying to use accurate terminology. Bluecherry-client = the client software... on the client computer. etc etc.

But thanks, I'll look into setting up a proxy. I assume if I keep the BC client pointed to NIC A it'll be smart enough to proxy to NIC B within the same server and pull the feeds that way instead of drifting back out to the 24p LAN switch and whatnot. I've set up proxy's before on things like Apache, but it's been a long time (a number of years) since I did that on the networking level. Time to bust out the man pages!

 

[jasauders]

Just wanted to follow up -- I received my 8 port gig POE switch a few days ago. This evening I installed it. The IP cameras were set to a 10.0.0.x address, along with "NIC B" within my Ubuntu Server. There was no magic voodoo to do, no proxy settings, no uplinks are connected, nothing. NIC A continues to work issue free on a 192.168.x.x network scheme, which pipes into my main 24 port LAN switch to the rest of the home network.

All camera traffic is segregated to the POE switch >> NIC B on server, and that combination alone.
All camera traffic is visible through the Bluecherry client. The server simply distributes the feeds/events/etc over NIC A to the main LAN, then to wherever the client system may be.
If I have to do any camera tweaks within the web UI, I'll just static IP a laptop to the 10.0.0.x range to the POE switch itself. This is such a rare occurrence, so it shouldn't be an issue.

In an interesting way, I basically have two networks and two entirely different server functions piping to the exact same box, except to totally separate storage devices internally.
Bluecherry pipes camera feeds via 10.0.0.x network on switch "B" >> NIC B on server >> dedicated WD Purple
Main network pipes all traffic via 192.168.x.x network on switch "A" >> NIC A on server >> 4x WD Red software RAID

While there's no cross talk, everything can still communicate. Yay for networking magic.

Even though I already had my POE injectors when I got cameras (thereby providing me with a "free" means of giving them POE), I'm so happy I picked up a POE switch. Infinitely better. I should have done this from day 1, despite the POE switch coming with an extra cost to boot. Darn financial priorities... Someday when I'm rich and famous I'll pick up a decent sized gigabit POE switch with VLAN support. Until then, this is a significant improvement.

Thanks again, nayr, for your insight.

 

[nayr]

im pleased you got it up and working, i doubted any voodoo was nessicary, its a pretty common setup.

 

[JuliusTheodore]

Which POE switch did you get?

 

[jasauders]

Which POE switch did you get?

I went with this gizmo.
https://www.amazon.com/gp/product/B00F6DL2FS/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

Can't really say much about it. It's only been running for a day, but it's quiet, runs cool, and does its job.

 

[jasauders]

So... one snafu I ran into was my newfound inability to pull in substreams. Let me explain... I have a Nexus tablet that sits on my night stand. It has no swipe-unlock-code-voodoo so if I press the button, BOOM it's alive with TinyCam pulling in my feeds. It allows me to see what's going on with minimal delay.

The catch is, by putting everything on a 10.x address scheme with the other NIC, I blocked my way for the Nexus tablet to connect to the cameras directly to pull in their substream. The wireless access is not in any way connected to the "cameras + POE switch + NIC B on server" path. Best I can do on the Nexus is call the Bluecherry direct URLs for the cameras. This works great. Love it. But the issue is I'm pulling the heavier, full resolution stream. TinyCam seems to auto-quit itself if I let a stream run for too long. Sometimes it's 20 seconds, other times it's 10 minutes -- no idea there... I thought this was just my 2012 Nexus 7 showing its age, but my Galaxy Tab and Nexus 10 do the same thing. The only common denominator is TinyCam does this when I am pulling in the bigger feeds. Substreams were never an issue. Even TinyCam in low bandwidth mode doesn't seem to change this behavior. As a result, I'm back to questioning how I can drive in my subs again.

So what I'm wondering is... why would I even need to go that "far" to put the cameras on an entirely different subnet/networking scheme. What are the consequences of me putting the cameras on the *same* scheme as the rest of the network, but just static'd outside of the DHCP scope? Thinking something along these lines...

DHCP scope: 192.168.1.10 - 192.168.1.149
(150-199 used for various other things, i.e. other servers, networked printers, APs, etc)
Server NIC A (for main LAN): 192.168.1.200
Server NIC B (for POE switch): 192.168.1.220
Camera 1: 192.168.1.221
Camera 2: 192.168.1.222
Camera 3/4/5/6: .223, .224, etc etc

The catch is, I'm not thinking simply re-IPing will make a difference as there's still not a link in between the 24 port main LAN switch and the 8 port POE switch. Even if NIC A and NIC B on the server are IP'd in a similar way, I don't suspect that things would just "magically" flow in the way I'd like (maybe they would?). I'd imagine I'd have two options: Either own up my last port on the POE switch to uplink to the main switch (meh), or proxy NIC A and NIC B to talk to one another, thereby allowing substream traffic on the camera to flow from the cameras themselves >> POE switch >> NIC B to magically find its way to NIC A, then back out to the 24 port main switch >> over wireless >> to Nexus tablet.

In short, I guess my original target has shifted slightly in an effort to regain my direct substream connections to the cameras. I still want the camera traffic to reside exclusively on the POE switch + NIC B, thereby leaving the 24 port main switch + NIC A alone, but still allow a wireless device (Nexus) to tap into the substreams. I think the physical wiring of everything will influence this to go in the way I like it, but it's just that last missing bit to bridge the two networks together that I need to nail down.

Time to bust open my old notes. I feel like I tackled this before with a massive LTSP thin client setup I did about 8 years back...

 

[nayr]

you cant get bluecherry to simply give you a substream also? I can can get all the streams from all my cameras by connecting to my NVR..

 

[jasauders]

you cant get bluecherry to simply give you a substream also? I can can get all the streams from all my cameras by connecting to my NVR..

Bluecherry has a low bandwidth and full bandwidth profile, which is switchable in the client itself. While the client is cross platform, it doesn't extend into the mobile arena (yet). It is easy however to tap into the Bluecherry streams using TinyCam/IPCamViewer/etc by using the generic URL/NVR preset, pointing it to the server-IPort/camera#. Thing is, I'm at the mercy of what the mobile app (TinyCam, IPCamViewer, etc) support at that point, as Bluecherry's low/full bandwidth profiles aren't available there.

It's pretty evident that the way I networked things is what blocked me out of this substream capability, as I was just drawing those streams direct from the cameras. I could easily put a spare laptop on the night stand, but I'd much rather leverage a tablet for this since, well, I have a tablet, and I don't use tablets for literally anything else, so that combination seems to fit nicely.

 

[nayr]

since the tablet is basically fixed, OTG Ethernet adapter perhaps?

I bet there is a URL that you can use to get the substreams, the app dont need developed.. I can grab main stream or substream via RTSP URI in VLC.. and thats basically all tinycam pro does, so your just lacking the knowledge of the substream/low bandwidth URL.. contact BluCherry, what are you paying money for if you can go to them for help.

 

[jasauders]

since the tablet is basically fixed, OTG Ethernet adapter perhaps?

I bet there is a URL that you can use to get the substreams, the app dont need developed.. I can grab main stream or substream via RTSP URI in VLC.. and thats basically all tinycam pro does, so your just lacking the knowledge of the substream/low bandwidth URL.. contact BluCherry, what are you paying money for if you can go to them for help.

The cameras do have a direct URL for the streams. Bluecherry does provide a direct URL for the streams. They both work in the typical setup without issue. The catch is, my current networking setup forbids that.

POE switch/NIC B = 10.x.x.x
Main switch/NIC A = 192.168.x.x

The two switches aren't linked. The two network setups do not talk to one another. With my wireless (for Nexus substreaming) being on the main switch, it inherently fails to understand that the 10.x network exists. I don't think this is an issue/limitation/problem with Bluecherry or my cameras pumping out the streams. It just happens to be the one snafu with the way I wired/configured everything. I just need to rethink how I can make everything play nice-nice while still maintaining some sort of segregation with the video traffic staying on the POE switch side of things.

 

[nayr]

its because your BlueCherry box is not doing routing, all you need to do is have it route that subnet and then add a static route to your router for that subnet going to your BC server..

however, it should work fine with out this... If you can get the MainStream directly from your BC Server, you can surely get the SubStream directly from the BC Server, this is a standard configuration.. if BC cant do something this simple then damn am I glad I didnt waste $250 on a crappy software NVR that cant even keep parity with cheap hardware NVR's.

 

[jasauders]

its because your BlueCherry box is not doing routing, all you need to do is have it route that subnet and then add a static route to your router for that subnet going to your BC server..

however, it should work fine with out this... If you can get the MainStream directly from your BC Server, you can surely get the SubStream directly from the BC Server, this is a standard configuration.. if BC cant do something this simple then damn am I glad I didnt waste $250 on a crappy software NVR that cant even keep parity with cheap hardware NVR's.

I would hardly call it crappy software. Everybody has different preferences. Some of my preferences include a PC/server base along with a Linux focus, and it running on a laughably low end assortment of processors is a pretty serious bonus. I could go on (no proprietary video exports, etc), but we'll call it there. Their support has also been pretty decent. Just one example: In the short time lapse between your last message and this message I'm typing, they have given me a solution. Turns out there is a direct URL for the low bandwidth mode. It seems to jump to the other NIC in the server, and as such, over wireless, without issue.

 

[nayr]

i told you there was, I was implying BC was shit if it didnt.. but your asking me to help you with a product ive never used so thats why I pointed you at there support people.

 

[jasauders]

i told you there was, I was implying BC was shit if it didnt.. but your asking me to help you with a product ive never used so thats why I pointed you at there support people.

I was figuring this was more of a network layer thing with the physical layout of how I structured things, and less about Bluecherry itself.

...now I know. Thanks bro.