Set up a V-lan, this is a good thing. This will allow you to from a networking perspective to not kill the network, and if you look at the above reports there are other advantages to it, most of our installs accross WAN's are done this way.
Question I like to ask is who is going to manage the network? If you add VLANs to the customers network then there IT department gets involved and I tell them they are the first group we are going to call when we have a network issue. Once they understand that they will be involved normally they tell us to build our own network. I prefree building our own network which we fully manage without having there IT department involved.
Depends on what you mean by "separate network."
Some advocate a separate physical network--with dedicated routers, switches and links, paid for as part of the security system and governed/operated by the security personnel or their contractors (which might be you).
Fewer advocate that while the physical network can remain the IT department's responsibility, a separate logical network should be created for the security equipment (i.,e via VLAN). The idea here being that IT can provide the underlying infrastructure but the security staff is responsible for all the equipment on "their" network.
When connectivity between remote sites comes into play, it makes much more sense to share wide area network connectivity with the IT infrastructure, as setting up and maintaining those links can be very expensive and require more extensive and classical IT networking expertise. The caveat being that it may be the existing wide area network links are already insufficient for video traffic, which of course complicates things.
My personal opinion (with which many here disagree) is that the best and most efficient use of IP technology comes from aggregating responsibility for underlying infrastructure with IT, then treating surveillance as just another customer of that infrastructure (recognizing that, in terms of bandwidth and performance requirements it may be the biggest customer of that infrastructure). I feel like arguments that say the IT infrastructure can’t “handle” IP video just forgives IT of their responsibilities to provide adequate infrastructure to meet the enterprise’s needs.
I recognize that politics can come into play that can completely perturb the above vision. Maybe IT reports into Finance or Facilities or some such, is always in the dog house for poor performance at what is perceived as too much cost, and has no real representation at the executive level in the absence of a CIO/CTO. Or maybe as a public institution the security system is being paid for via a grant or some funding source that requires the money ONLY be spent on security and prevents it from being spent on “IT” etc. And of course there’s pre existing corporate culture, bureaucracy, politics and personal history that I know in public institutions can cut deep into effectiveness.
I’m just saying that in terms of what IP is designed for as a technology, stacking applications on top of a shared, common, well managed infrastructure is its technological vision.
I was hoping for a broad spectrum of thought & suggestion, and that’s what I got. Thanks All.
Our organization has a robust department of network professionals. I’m lobbying for their early involvement in the V-LAN concept-development process. By this means, the network folks will be advised of video bandwidth requirements, and can design a standards-compliant V-LAN architecture to support it. Because of their involvement, it will be expected that the V-LAN will fall under the existing standard monitoring & service provisions. The idea is; to let the network folks support the network hardware & infrastructure, while also taking advantage of established network monitoring & service procedures. The Security folks will operate the VMS like a client.
It’s a grand vision, which I’m sure will work out perfectly.
PS: IPVM has become a valued resource to me. I'm willing to pay the anual fee so my boss thinks I'm much better-informed than I actually am.