Member Discussion

Should I Use Multicast Or Unicast For A Large Genetec System?

Consider my situation an enterprise/campus/federated or larger system. All cameras and related storage [servers, DVRs, etc] are setup on a video VLAN. I am told we can use as much bandwidth as we want--unlimited. If there seems to be a limit, let the network/IT know and they will figure out how to make the pipe bigger.

Current status is the video storage is a hodge-podge of various units and VMS and located in various buildings all over campus [100+].

Specific cameras are viewed at various office [100+]locations all over on campus and off campus sites, mainly by the facility/building managers, security officers, campus dispatch, and myself for maintaining cameras and systems. We might have a total of 100 to 200 viewers [clients], but by all means they do not view their own specific cameras all the time -- who knows really other than myself and dispatch who views regularly. The most anyone client might have access to view is 40 cameras and do they?..doubtful. Most video viewed is after the fact.

We are transisitioning to centralized system. Most all video will be sent and stored at centralized data center. The platform of choice is Genetec.

Now the multicast query -- I am told it is best to setup my cameras to multicast oppose to unicast. But my understanding too is I need, not only the cameras, VMS configured, but our network/router/IT people to also configure the switch ports to be multicast. The network/router/IT people say this is unnecessary because we can have as much bandwidth as we want [we are on a separate video vlan]. I don't have a good understanding to tell them otherwise. They say if we need more bandwidth -- let them know--they'll give it to us [and they do have big pipes]. They say they hesitate using multicast because of the potential havoc it can create on their network.

The question is -- is multicast any better to have if we can have all the bandwidth we want? Are there still limitations? What would the limitations look like? How do I explain that multicast is a good thing for our video system to the network/router/IT people so they understand. How do they avoid the multicast havoc..or is that just urban tales?

**apologies this is long--but when I tried to edit out items --they seemed important enough for clarity, so I kept all information here**

Thank you!

A, thanks for the detailed explanation.

First, I recommend you map up / estimate how much bandwidth total you need (e.g., bandwidth from cameras to recorder and from recorder to clients). IT is saying that bandwidth is unlimited but there must be some point where even they will balk (is that 500Mb/s, is that 5Gb/s, 15Gb/s, etc.).

In particular, to analyze whether multicast will be beneficial, you want to determine how many clients are going to simultaneously view the same stream.

For example, if you anticipate 100 clients / people all looking at the front door camera of Building #1, this is the best case scenario for multicasting. Let's say it is a 2Mb/s stream. Instead of sending out 200Mb/s total (2Mb/s x 100), you might be able to send just 2Mb/s and have the multicast network replicate / duplicate the stream as it gets closer to the clients.

However, if you anticipate, 1 client / monitoring station watching 100 cameras at once, multicasting provides no benefit because all the streams are unique anyway.

Once you analyze the multicasting 'max' scenario, you can determine how much bandwidth savings are theoretically achievable with multicasting. Share this number with IT and see what they say. If they respond "Wow, that's a lot" look more closely at multicasting. Alternatively, if they shrug it off, I'd be inclined to go unicast only.

Finally, it is not an urban tale that multicasting requires greater time, skill and equipment to deliver. If IT really does have the bandwidth (and you can validate it with specific numbers) than you are far better off following their lead. Also, think of it this way, if you push hard for multicasting and they have problems implementing it, it might cause more internal issues.

Nowadays Multicast for LANs is not so hard.

The majority of networking equipment is already prepared to handle the extra load (when you enable multicast, basically the switch is doing the work of providing the video stream and duplicating packages after the initial comunication with the camera was already started).

And configuration is not that hard if you plan a little bit ahead.

In the IP Camera world the only thing you need to make sure is what IP are the cameras defaulting to when using Multicast.

Because if you have lots of subnets you can end up having duplicated multicast address and then it's multicast storm all over and the network will stop.

For the network switches It is as simples as:

interface Vlan2
description Security Cameras
ip address
ip pim sparse-dense-mode


If it's that simple, then A can subcontract it out to you say for $1000 (it's only 1 minute at the command line) and if anything goes wrong, you'll commit to fix, sounds fair?

Planning phase could take some time depending of the size of the network. If the customer already has a topology, somewhat documentation and it's not a big campus, 8 hrs would be a reasonable time.

Output of the planning phase would be the switch scripts. For the access switches this would take no more than 30 secs, but if you have cats6500 (big distribution / core switches) it can take more time, 10m or more just to reload the box.

For the usual medium network just 1 more line in the interface script and it's done.

1 day for testing

1 day for deployment and on site help.

3 days for a Medium network. three-tier design network with 50 access switches. 1000 cameras.

That's more of a CCNP/CCDP job. Don't know about US rates, etc...

In Brazil a Big Network Integrator used to charge U$55,00 per hour.

If anything goes wrong, just reload the backup scripts....

"If.... it's not a big campus"

A says they have 100+ building. That's a fairly big campus.

What if some of the switches are not from Cisco or don't support multicasting? What if something goes wrong with multicasting?

With 100+ buildings (and presumably 1000s of cameras), if you are bidding 8 hours site unseen, there's a lot that can go wrong and I am betting you are going to lose your shirt.

It's not quite as simple as unicast vs. multicast. With Genetec you have the option of multicasting live video direct from the camera to client stations or unicasting from the camera back to the archiver and then multicasting from the archiver / redirector to the client stations. Whilst the second approach does increase server load (and potentially tromboning of traffic if viewing stations are located close to cameras), it does have the advantages of:

(a) all multicast traffic originates from a central location, making it easier to understand / manage the network requirements

(b) you can specifically define which subnets do and do not support multicast in Config Tool, meaning that it's not necessarily an all or nothing decision if some parts of the network can support multicast streaming to clients and some cannot (will automatically fall back to unicast).

Multicast offers the ability to send different resolution feeds to viewers/recorders. If the viewer has 4/9/16 images/monitor, then sending the max resolution may be wasteful. It also localizes traffic in that the one data stream goes from the camera to the likely nearby viewing station while the other goes off to the centralized recording location. The comment missing so far is that using unicast means the Genetec recording system is now responsible for "echoing" the camera feeds back out to all the viewing stations possibly creating a large amount of traffic from the central location (bottle neck). It also creates a higher processing load on the Genetec core servers and may add some lag at the viewing stations. That will need to be evaluated by your client.

It would be interesting to know the number of cameras per building versus viewing stations per bulding as well as their expected bandwidth to get an idea of the total data flow.

"Multicast offers the ability to send different resolution feeds to viewers/recorders."

No, that's not unique to multicasting. What you are describing is multistreaming. You can do multistreaming with unicast.

As exciting as all this technology stuff is I have a simple solution. This is why Genetec employs sales engineers. Their job is to evaluate both the current requirements and potential future needs for design impact. Then they have the ability to communicate with the IT department and Customer those options. The best guy I knew with them unfortunately now works for Veracity.

I definitely think it's useful to have Genetec sales engineers provide input but an end user who simply goes on a manufacturer recommendation is not doing proper due dilligence.

Thank you all for this informative discussion - very helpfull to my scenario.

Never do multicast. It is not securable, it requires special configuration on the network gear, and it makes your video available to the whole network whether you like it or not. If your vendor tells you UDP is "easier" than TCP, they don't understand networking or are selling you crappy cameras.

Is this the first comment to ever have a vote in each category?

The OP said "how do I explain to the network people Multicast is a good thing. The decision to go Genetec has been made and now it's a design session. It might not be a good idea to implement multicast. GENETEC can provide information for the decision based on historical installations and technical knowledge as it applies.

| ...they will figure out how to make the pipe bigger.

Yikes, your IT people think networks are made of pipes?

Seriously though, you should definitely do some modeling of bandwidth across your network structure; you will have to estimate bandwidth anyway when you plan for how many cameras to assign to each archiver. Plan for the future, not the present.

Since you have cameras already in place, hopefully your IT folks are familiar with the network load that these cameras will impose and are not just assuming that there will be negligible load - cameras can use a lot of bandwidth, especially hundreds of them.

As someone mentioned, get Genetec involved in the discussion; they do validate network designs and you (and your integrator if you're the end user) should be going over all this with them.

Are your clients on the same VLAN? From your description, I am assuming not. If your clients are on the same VLAN, then hopefully your network switches support IGMP snooping; if so you are all set. If you have clients on different VLANs then you will need IT support to actually route multicast - it's 90% understanding, 10% implementation.

With Security Center, multicast will benefit you only when you have multiple people viewing the same live streams at the same time. Most importantly, this will reduce the bandwidth on your archive servers (servers that manage and record cameras) and quite possibly will be the determining factor in how many archivers you need.

On a multicast capable LAN, Security Center controls multicast streams for cameras by either directing the camera to send the multicast stream (for those cameras / encoders capable) or by having the archiver itself multicast the stream if the camera is configured for unicast or incapable of multicast itself. If multicast completely disabled I believe that it is the archivers, not the cameras, that send live video to clients. I could be wrong on this as I have not worked with SC in a unicast only environment.

A few other notes on multicast in Security Center: SC turns multicast off when there are no live viewers, switching back to a unicast stream when only recording; this can save on multicast addresses. SC also allows you to indicate different capabilities for different LANs, so you can configure your video LAN for multicast but have all external LANs be unicast only.

Interesting comments all over the board!

1. I view the discussion from a bandwith and bandwidth management viewpoint. As an IT person, I learned long time ago, adding more bandwidth to solve a problem/issue does not solve the problem, only delays it. There are other items to consider such as server load.

2. As far as multicasting and security, that is part of the reasons to use VLANs and access lists (ACL).

3. True, setting up muticast on some switches may involve a few steps or a script but can be detailed if a fabric (fabric switches) are involved, sparse versus dense mode configurations. I read campus environment, video vlan ...

4. With Genetec and possibly others, it is one has to consider licenses when deciding to view cameras either directly, via the archiver or both.

In short, gather the respective teams at the war table and plan! plan! plan!

Wow! I posted on another discussion the fact that, it appears, most people still have the belief that using multicast on the switches (not having the server replicate), is difficult, requires a lot of pre-planning, can cause havoc on the network if done improperly etc, etc...and even on this post earlier the comment "They say they hesitate using multicast because of the potential havoc it can create on their network" from the IT staff seems to validate this premise. the problem is that everyone is still trying to solve the "multicast issue" by designing around it or finding reasons why it is not needed at all.. what if you had a network that could support Unicast and, with only one line command at the edge switch port "SPB multicast enable", the whole network is now not only unicast, but multicast enabled without the use of PIM, rendezvous points, bootstrap routers etc, etc... that causes all the havoc if configured incorrectly? would that be interesting?

People need to be open to looking at alternative ways of designing their networks and they won't have to worry about creating any havoc and they can get a secure, flexible network that can accommodate not only 1 viewer, but instantly accommodate many viewers in case of an incident.

Lorraine works for Avaya, just so others can understand the context of her post.

I do remember a customer installing new Cisco switches to update their system and forgot to order the version that supported multicast on the remote switches that most of the clients were connected to.

It was about a $200,000.00 mistake that the Cisco VAR said "Hey, I can upgrade those, but it costs more" after the client spent his budget.

I like the plan, plan, plan idea.

It's 2016, multicast is still a bad idea because camera vendors still use it as an excuse to sell underpowered cameras. Legacy endpoint security solutions don't help. Doesn't matter if your studly switches and pipes can handle it, it's still a bad idea except in tiny workgroups. It's not end to end secure also.

It's 2016, multicast is still a bad idea because camera vendors still use it as an excuse to sell underpowered cameras.

Do you really think they would be making more powerful cameras if it weren't for the existence of multicasting, used by only a small percentage of users?

VMSes also let one camera stream be multiply delivered to multiple clients without additional camera resources, by the same token should they be shunned?

In any event multicasting is often done from the VMS, not the camera.

It's not end to end secure also.

Yes, it's vulnerable to a local LAN attack. But, video feeds of all the entrances and lobbies might not be considered something that need protecting from people inside ones own organization. Yes/No?

Multicasting from the vms for multiple viewing platforms is not the same thing, I'm talking about multicast from the camera. Yeah, the VMS in the FBI van feeding signal to all 42 cop cars clustered outside may in fact want multicast, for that localized workgroup. All the cameras in your 24 square mile airport should not be using multicast to get to the vms (DVtel does it that way, for example.)

I really think the vendors don't understand protocol stacks and how to use embedded software. I don't actually think it has anything to do with customer requirements.

Yeah, the VMS in the FBI van feeding signal to all 42 cop cars clustered outside may in fact want multicast, for that localized workgroup.

I literally looked outside. :)