Control network IP scheme change and automation

[Ioannis Syrogiannis]

On one hand, I agree, Bruce. On the other, there is so much time and effort that one dedicate to such a task.
I tried to reason with the person that I communicated and I got responses that do not address the issue.
After once or twice, if you don't have the ability to talk to decision makers, repeating yourself to policy followers doesn't move things forward. The supplier doesn't piss me off, they let me down.That's the reason that I am trying to figure out alternative handling.
If no alternative seems reasonable, reason calls for another solution.
Functionality, from my point of view, is both capacity and operability. Having a kitchen knife that cuts smoothly but has no handle long enough to hold properly, beats the purpose. You either have to move what you want to cut, smear or support around the knife, or you have to use one that does the job for you.

[Steve Guttag]

Steve: fair enough, but the DSS scheme does have problems. It was designed when 100Mb networks were standard and could saturate if traffic was not isolated, and drop packets.

Not necessarily true as Dolby supplied 1G switches as their switches (SMC brand) and the ports on the DSS servers were 1G ports

So each DSS scheme auditorium is on a separate /25 network. Advantage is limited traffic avoiding saturation and - for example - that server 1 can't talk to Jnior 2 if you mess up the addressing and thus control the lights in the wrong room. But let's presume that the tech is competent and not doing that. It also means that, if something doesn't execute commands on #1, like a CP750, you can't temporarily readdress the #2 server to use the #1 CP750 to help diagnose what the problem is: #1 can't communicate with #2 devices.

Not true at all. As described in my previous post. If you set up the routing table in the router, everything CAN talk to everything. There is a reason that they have you designate, for each device in an Auditorium that the Gateway is the server's auditorium IP address (e.g. 192.168.2.129 is server 2's IP Auditorium IP address). If server 2 wanted to talk to sound processor 1, it would see that 192.168.2.136 (CP750 standard IP for auditorium 2) is not on its subnet so it would send the request out to its gateway, the router you would would configure at 192.168.241.1, which, would send the packets to 192.168.241.4 (Theatre 2's Theatre NIC) which would then route the packets to CP750 #2.

Here is the routing table (presuming my graphic goes up in the right place...I'm still getting the hang of this new site) I set up on a Sonicwall for a 3-screen systems. It isn't that hard or complicated (trust me, I'm not that IT savvy at all. As I like to say..."I know what I know, but not a bit beyond that.")

Screen Shot 2020-03-28 at 10.14.53 AM.png
Screen Shot 2020-03-28 at 10.15.19 AM.png

Using a /24 segment gives you 255 usable addresses. If you have up to 10 screens that gives you a lot of room using a logical numbering scheme like x.x.x.01 for server 1, x.x.x.02 for server 2 etc, x.x.x.11 for projector 1 and so on. I can't think of any screen setup that could possibly have 24 different networked devices.

I have numerous sites that would have more IPs than that on a single screen. I have a lot of sites that have some substantial A/V. You can blow through IPs pretty quick once all of the Blu-rays, switchers, controllers...etc. get added in there. 10IPs per screen is even way too tight for me. I have sites with series 1 and even GDC SX-2001 servers with 3D...so you may need an IP for projector, server, server's SM, 3D, TI boards, Blu-ray, network switch (if managed), automation, sound system, scaler/video switcher, laptop interface. I'm up to 11 without breaking a sweat. Mind you, like consistency so if I assign a device an IP (4th octet) for one site, if it is common to potentially all sites, it gets that number for all sites. For example, while we have or have the potential to take on a series 1 projector, I will always block out those IPs for the TI boards of a series 1 and while we have or potentially will have a GDC HDSDI based server, I'll always block out the IPs for its Security Manager...for EVERY site. As such, I've adopted the /23 scheme, which consumes twice as many 3rd Octet numbers but we're small enough I'm not worried about having THAT many sites. Heck we use a Class-B numbering system so we aren't on the more popular Class-A 10.x.x.x networks of the "big boys."

I know and respect the decision to have the type of scheme you've described as it is pretty easy to work with (by anybody) and even mentioned it in my example above and even discussed how one can quickly expand it for lower-screen count systems if more IPs are needed for a particular screen/screens. Again, I had to have a Cinedigm system and I hadn't developed my own opinions, at that time so that is the system I used as the nucleus of what I do now. I don't proclaim it is better but it does, seemingly, do what I need it to do, which a consistency throughout what we service from 1-20 screens pretty well. It isn't too terribly hard to figure out. I have a spreadsheet that lists the numbers (auto populates too) for each site and I go out of my way to NOT hide IPs...if the device doesn't show it, I normally put a P-Touch label as close to the NIC as possible. Any competent tech should be able to figure out the scheme, even if they hadn't worked with a Cinedigm system before) pretty quickly because, the screen number is in the IP and there is uniformity in the groupings.

There are advantages to having everything on one segment.

Agreed.

I suppose the DSS does route the theatre network to its auditorium network but many small sites do not have a theatre network connected.

In a DSS system with Multi-screens? I've yet to find one but I'm sure you'll have some case-in-point. The DSS system had the "free" TMS for up to 3-screens (though you could eek out 4 or possibly 5 if it was a late-model DSS200 that could handle the TMS overhead). I can assure you that all of our sites with DSS servers that they are all interconnected in some fashion. It was one of the big selling points to our independents/art houses that typically had 1-3 screens per site. The cost was a CAT6 cable plus a single switch per complex...no money there.

And many sites have mixed server brands...

That is definitely going to be the trend as all equipment has some sort of usable life. We are JUST starting to see DSS servers have some geriatric issues. That said, only one DSS200 server, for us, has yet to be retired. That server came back as a DSL200, however, to upgrade another site from a DSL100.

...especially now when a dead DSS is essentially irreparable.

Only if a Mediablock (CAT862 or CAT745 or DSP100) outright fails. Dolby will still put in the 10-year battery on a CAT745 that has a simple certificate battery failure. The DSS servers all use Supermico motherboards, which are still obtainable through normal service supply sources and the RAID controller was 3WARE...also still available for similar sources. Power supplies and the like are also Supermicro and we haven't had a problem sourcing them either. Obviously, HDD are not a problem at this time. So really, it boils down to Mediablock.

Even Dolby DSS support techs are less than fans of the DSS scheme.

I'm sure, like most things, I would depend on the person you speak to and when they started with Dolby. I'm not claiming it as THE best scheme out there. It is dependent on a relatively unique feature of the DSS like (internal router) and I admire it for being nearly effortless to have essentially unlimited IPs. Compared to a system you advocate, it has over 10-times the number of available IPs per screen. And, believe it or not, you could even set up several "Mini-Plexes" within a complex too (e.g. put Screens 1-3 on its own Server 1 driven TMS, put screens 4-6 on another TMS driven by server 4 and so on, without buying a DSL100/200). It operates at 1000 Base-T going back to the DSS/DSL100 days and required a minimal amount of networking or networking knowledge. I admire it for what it could do.

It isn't the system I've personally adopted and I have even converted some complexes off it to the scheme I've explained elsewhere to get our customers in a more unified system that is not server-dependent on it to function.

With respect to Crestron. You are either in the club or you are not. There really is no inbetween. Even if you have Toolbox, you are very limited in what you can do except for those devices that are designed with Toolbox as their primary configuration device (e.g. HD-XSP). One cannot really just dip their toe in the water of Crestron (or AMX, for that matter), you either jump in or you hire someone to do it for you. That said, if a job needs the likes of Crestron, we have a very good integrator that can handle that for us as as subcontractor. There are VERY few sites where this is the case anymore. But there if there is a lot of AV and you want a ton of flexibility, Crestron, in the hands of a talented programmer is VERY tough to beat.

We are now exploring Q-SYS for much of our control systems though we have not abandoned using the EPRAD eCNA on all sites yet. Their box (like JNIOR) has a lot of out-of-the-box value that is cinema specific and the reliability is about as high as it gets. Also, we don't use Q-SYS on all systems, at least not yet. (Note, JNIOR now has a Q-SYS plugin for better integration.

If it were me on your site, if I didn't need what the Crestron was doing, I would replace it. If I needed it or would essentially just replicate it for a fair chunk of change, I'd seek out an A/V house that would get you Toolbox or come up with a fair price to come out and change the IPs as a 1-time fee and then you'd have a connection if you wanted it changed (functionality) at a later date too.

[Gordon McLeod]

The scheme we use is
192.168.100.xxy
xx is auditorium number IE aud #1 is 01 etc
y is the device as follows
1 server
2 som ip
3 series 1 projector
4 series 2 projector
5 sound processor
6 DAX 602
7 VI caption
8 Automation device
9 NAS

Media network
172.16.1.1xx xx is auditorium number

[Bruce Cloutier]

I tried to reason with the person that I communicated and I got responses that do not address the issue.

Yep. All you can do is try. They say you can vote with your wallet. In my experience, even at that when they lose the sale they don't get the point. Or, do they even notice? Also, at the time of purchase you really don't know what hidden issues you will encounter. It is very frustrating even for manufacturers. We buy equipment too. I have production equipment that demonstrate ridiculous software shortcomings. I think that is why in my old age I am so DIY.

We are now exploring Q-SYS for much of our control systems though we have not abandoned using the EPRAD eCNA on all sites yet. Their box (like JNIOR) has a lot of out-of-the-box value that is cinema specific and the reliability is about as high as it gets. Also, we don't use Q-SYS on all systems, at least not yet. (Note, JNIOR now has a Q-SYS plugin for better integration.)

I was really looking forward to discussing our expanding our role with Q-SYS this coming week at CinemaCon. We were going to be right across the isle from them. We have hopes of developing more business in the A/V sector perhaps with their help. We've exhibited at InfoComm before and I was thinking that we would again. Of course now things are setback. I expect our business to be soft for the balance of the year. That assuming we are able to restart sometime soon. We have R&D efforts underway with an eye towards expanding the line with more rack mount JNIOR implementations (like we've discussed here now in the archives). There are some good ideas on the table but I expect that we will have to set them aside for a while now.

It is much more gratifying to partner with companies rather than compete with them.

[Mark Gulbrandsen]

I am with Steve on using the Cinedigm scheme. I adopted that from the get go, and stuck with on all the systems I put in. The one exception was single screen installs were all just simple 192.196.xx.xx type configs. You get to doing two or more screens and it requires some IP layout and the Cinedigm was easy. Another reason to use it is many other techs are familiar with it.

Mark.

[Steve Guttag]

I'm not sure on agree/disagree. There are valid reasons for many various schemes. The Cinedigm scheme works for me, thus far. I'm not sure, if I had to come up with it from scratch, if I would have done it that way. A downside is that by auditorium, equipment is not contiguous in IP but I consider that somewhat minor. When I deal with traditional A/V company types in an integrated system, it drives them a bit batty because they will put up IPs sequentially (If they have four MIC receivers, for instance, they will want them all next to each other rather than in four different parts of the IP scheme. But this is what I mean one should look at what your needs are and think ahead as far as possible to not trip over oneself when you add that next thing.

For Q-SYS, I decided to do my own scheme and it is similar to the more basic scheme. I use a Class-C (192.168.x.y) where Q-LAN A is 192.168.150 and Q-LAN B is 192.168.160. The forth octet 0-9 are common to the complex (Top tier switch, CORE driving multiple screens and its redundant core, that sort of thing. .10 - .19 is Screen 1's Q-SYS stuff which could be its own CORE (so one can have separate cores for every screen with my scheme and/or larger cores driving multiple screens), amps, touchscreens...etc. If the screen needs more than 10 devices, it rolls over from .19 to .110 (as I mentioned before one can do for smaller screen counts). ATMOS rooms, since they can gobble up IPs and operate on their own clock, get their own ranges. QLAN-A starts at 192.168.171.x for screen 1 and QLAN-B starts at 192.168.211. for screen 1. The scheme ensures that there are never conflicting IPs in just about any size plex, ATMOS theatres can have over 200 IPs, each, without taking away from other Q-SYS IPs that may be sharing a core or other devices (streaming audio).

[Bruce Cloutier]

Wouldn't it be nice if local Name Resolution were more universal, reliable and actually usable?

You can get to a Series 4 JNIOR using its hostname provided that you haven't populated that with characters not becoming of a hostname. But, it is not reliable. I have not implemented the NetBios name resolution. There are apparently 3 or 4 schemes for name resolution on a local segment and if you look behind the scenes most systems try one after another to get the job done. But then configuring connections between systems most want only the IP address. Thankfully still IPv4.

[Steve Guttag]

I don't know fi that would be better or worse, really. You then start to have to have a methodical naming scheme and stick to that. Is theatre 4's automation 4Automation or 4JNIOR or 4AUTO...etc? Do you keep your devices with a more generic name or the model specific...leading zeros.

And even then, you may not be able to figure out, easily why one device can't "see" another. With an IP scheme, you can follow what things are or are not within the same network and what it takes to route to them.

[Mark Gulbrandsen]

The Cinedigm scheme works for me, thus far. I'm not sure, if I had to come up with it from scratch, if I would have done it that way.

Well, it allows for changes, expansion of equipment and many other techs are familiar with it. Since I started with systems and TMS's layed out that way, it made a lot of sense to continue with it everywhere else.

Mark

[Mark Gulbrandsen]

This is the IP Scheme I used and it does identify the screen number

[Steve Guttag]

Yeah...that is definitely a variation on the Cinedigm scheme. In fact, it looks like a Strong modified version (the Media IP would have been a 10.195.65.101 for server 1, if a true Cinedigm scheme but Strong kept all but the 2nd octet the same for the media player. Cinedigm didn't designate all of the potential IPs. Note, it was designed around a 40-screen system. Here would be how I populated it out for 40-screens:



You can see some variation there. I opted to associate the Closed Caption device with the server (letting it end in the same IP as the server IP but with the 3rd octet one higher) and I associated the touchpanel (or computer) for the projector have the same 4th octet as the projector. I mostly have Barco projectors and many/most have either a touchpanel or a dedicated micro PC associated with them. I also accounted for GDC's Security Manager for their HDSDI based servers. One quickly runs out of IPs here but most don't have to deal with more than 20 screens in a complex (at least I don't).

Here is how the spreadsheet changes as we drop to 20 screen maximum:



Most of the new IPs are already filled in for me (reserved) though I'm not sure I need to allow for both a customer furnished booth computer on EVERY screen as well as a server computer (most servers are now Web based UIs so having a chromebook or something like that at each screen isn't unreasonable. So one of those is likely to go to make room for something else...this thing has evolved. The 3D controller (Dolby 3D) likely will be able to be reallocated down the road too though 90% of our existing 3D systems are Dolby 3D. Obviously, no new ones are going in and Real-D doesn't need an IP. That said, the bulk of our theatres are 10 screens or less. So it expands to this for 10-screens:



The reserved ones keep one from using an IP that COULD be in use by a higher screen count. That is..say .51 isn't used, yet by the 20-screen version so it is reserved in the 10, 5 and 1 screen versions. If a new device that would likely be used in new complexes, going forward, then it should be assigned in the higher screen count first, and then ripple through to the lower screen count sheets. If a particular complex has a busy IT need, then that sight might, uniquely consume an available IP. At 10-screens, I typically have plenty of IPs available still for "standard" devices. My most popular sheet is the 5-screen version (for screen counts 2-5) and would merely double the amount of available IPs again. So again, the lower the screen count, the more IPs I have yet once an IP is assigned to a standard device (e.g. projector) that IP ripples through all sheets so it is consistent. One could certainly do the same thing for the other style (4th octet contains screen and device number). That just isn't the way I went over a decade ago.

For my Q-SYS scheme, I used the other, and potentially similar method, which keeps things more grouped by screen, than by device:

[Mark Gulbrandsen]

I actually stayed away from the 192.168.xx.xx realm completely except at single screen theaters and in very early installs I did with Series 1. A good friend that's an IT guy for The Army said using 192.168.xx.xx scheme on a large system just invites hackers. So all my systems ended up being based on 10.XX.XX.XX at his suggestion.

[Steve Guttag]

192.168.x.y, 172.16.x.y, 10. x.y.z are all examples of "private networks." There is nothing inherently more hackable about one over the other aside from the potential number of IPs. I use the Class C 192.168.x.y for IPs that are NOT site specific (Q-LANs, in my case...there is no need to make those all have completely unique IPs across all sites). The only device that could possibly need a unique IP would be the CORE itself. It can give you access to the rest, if needed. You won't find too many IT departments using too many Class C networks because it also has the fewest number of IP addresses and every network device seemingly comes with a Class C IP (or DHCP) preset.

For our main networks, I chose Class-B because we're a small company and Class-B offered plenty of potential IPs for our needs and also pretty much ensured we didn't have any overlap or same IPs as one of the major NOCs. For those sites that needed/wanted full NOC support (e.g. for the VPF programs), we could sub that out without any IP overlap. It has worked out very well.

[Greg Routenburg]

The 192.168 Class C are not inherently more hackable than any other but they do present a slight vulnerablilty if the security settings on a gateway router are left unconfigured. This happens all the time by lazy IT people or people who just don't know any better. By doing some basic network sniffing, one can make an educated guess about what the default network is for any given commercial router and then attempt to spoof one's way into/through it. If the hacker gets lucky and the firewall settings aren't done well, it's possible. A well designed IP scheme should be subnetted to the user's needs. It's obviously more critical when you're owning a block of public IPs like an ISP but I equate it to neat cabling. If it's worth doing, it's worth doing properly.

[Steve Guttag]

Precisely!

And note, my QLAN-A doesn't even have a gateway and depending on the core size/model, neither does QLAN-B (for me). If one has cause/need to be on the QLANs, one should have a physical connection...only audio should be on there, unless QLAN-B is being used for control (hence I may have it on a gateway...but on medium and large cores, there is an AUX network for control so even QLAN-B is all by itself too as a fully redundant network.