|
|
 
|
|
Author
|
Topic: Auditorium vLan networking
|
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 10-31-2017 06:58 AM
If you're experiencing this kind of problems on your network, then VLANs are not going to help you. VLANs create separate broadcast domains, but they're not going to speed up your network, unless your problem is a lot of broadcast traffic. And if there is an excessive amount of broadcast traffic, you either have a HUGE (really HUGE) network, or something is wrong.
In your case, if you're doing a file transfer from A to B and C and D cannot reach each other while doing so, you got a pretty shitty switch and might consider replacing it with something that can handle all ports at wire speed. Either that, or there is something wrong with your network architecture, like an over-saturated link between separate switches.
As for separate VLANs per auditorium: Why? You would also need a separate gateway per screen this way and if one screen would need to communicate to e.g. a TMS, it needs to cross this gateway.
VLANs should be segmented by function, not so much by physical rooms. So, splitting your auditorium LAN, office LAN, guest LAN, wireless and maybe POS network into separate VLANs with a firewall in between sounds like a good idea, splitting your auditoriums into VLANs feels like just a pain in the back.
If your subtitles drop when you do a DCP transfer, I guess you've got something else going on, something like a loop or something else that causes excessive broadcast traffic, like a broken device or a shitty switch.*
Excessive broadcast traffic can severely impact the performance of network connected devices, because they need to act on all broadcast packets they receive.
* More expensive switches offer some protection against "broadcast storms".
| IP: Logged
|
|
Steve Guttag
We forgot the crackers Gromit!!!
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 10-31-2017 07:16 AM
Gunnar,
My first question is, did you set up the networks "The Dolby Way" buy using the Theatre and Auditorium networks?
If you did, the topology should look like a "Spoke-and-wheel" network with the Theatre Network in the middle. By design the Dolby networks have N+1 VLANs where the auditorium networks are all completely separate. Each server has an internal router to allow communication between the Theatre network and the auditorium BUT you have to put the routes in your Theatre router to list each respective server's Theatre NIC as the gateway to that theatre's Auditorium LAN.
In this manner one can be on the Theatre LAN and "see" every auditorium LAN so long as that respective server is up. Content only moves on the Theatre Network (as I recall, the key criteria to the Theatre switch was gigabit and jumbo frames).
The scheme is slick in that one has essentially an unlimited number of IPs available (each auditorium can have upwards of 128 IPs) and one can have as big a complex as they want (over 200 screens) with as many clients as needed (you have 254 IPs to share between the clients and servers, essentially a bottomless pit).
It is true that the Theatre network is only gigabit so as you are moving content, the more you move, less bandwidth that is available for the rest on that single gigabit cable/switch.
I don't know how many screens are on your network and how much content is moving about when you experience the problem but I have an 8 plex that was using the standard Dolby scheme and it wasn't an issue. Yeah, you would get slow downs when a lot of content was moving but it was never so bad as you couldn't talk to a CP750.
That said, MOST complexes around the world use a two concentric circle scheme where by the Theatre Network is treated as a media network exclusively and the Auditorium network is treated as a big management network.
What I have done, and prefer to the standard Dolby scheme is to have the auditorium network be one flat VLAN and likewise for the Theatre network (concentric circles). Via your router, you can set up the routing/gateway to allow communication to either from your computer but the bulk of your communication would be on the auditorium network to the individual pieces. VNC works on either Dolby NIC. The only reason to be on the Theatre network, at that point, is to use Jupiter client (it has to log into the "Management" for the Dolby network). Presuming you are using either a DSL100/200 or it is a mini-plex (3 or less servers with one as the TMS), then from the Dolby TMS standpoint, the Theatre network continues as the "management" network for just the TMS
So what you are left with is the Theatre network to just move content and the Auditorium network to communicate with the individual devices (servers, sound processors, automations...etc.). You won't get the slow downs because your communication with the sound processors won't depend on going through the server that may be busy sending/receiving content. You also won't depend on the server being up to talking with things on the auditorium network.
If you elect to do this, I would turn off the internal router since you will have a router doing a router's job and won't need N+1 routers trying to bridge the two networks.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 10-31-2017 09:06 PM
The basic operation of a switch is pretty simple, especially if you ignore multicast for a moment and stuff like loop prevention via *STP/BPDU packets. Then there are just two types of traffic: unicast and broadcast.
A switch simply keeps track of which mac address is behind which port by simply learning it and administering it in a table. Once it sees traffic from a certain mac address move to a new port, it will simply update the table.
Once it receives traffic for a certain mac address on a port, it will look in the table and locate the corresponding port, it will then repeat this packet on the corresponding port. If the receiving mac address is not in the table, it will just discard the packet. If it's a "managed switch", it usually also logs such an event by increasing an administrative internal counter somewhere.
If the packet was addressed to the broadcast address, it will repeat the packet on all ports, except the one it was received on.
Now for multicast traffic, there are certain extensions to handle them in a smarter fashion and to learn which ports are participating in which multicast groups. In most cases, they're not enabled or the switch lacks the functionality. In that case, multicast is treated like broadcast traffic.
Now, Ethernet was conceived as a bus protocol, it's therefore acceptable to see unicast traffic of other devices on your device. Usually, it should also not negatively affect the operation of this device, as those packets not directed to the device should be dropped by the hardware ethernet implementation already, with the exception of you putting the interface in "promiscuous mode", in that case it will actively process ALL packets it receives. Stuff like Wireshark will put your interface in that mode.
Now, a good switch should never forward traffic to a port that's not supposed to receive the traffic, besides broadcast (e.g. ARP) and multicast (e.g. DHCP) traffic obviously. If you still see this traffic, then either your switch is a hub (which fortunately have become rare beasts), your switch is crappy (unfortunately, there are tons of crappy switches out there, also from halfway reputable names like Dell, Linksys, etc.) or some feature like port mirroring has been activated.
| IP: Logged
|
|
|
|
All times are Central (GMT -6:00)
|
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic