ATEM Switcher Panel loses connection when on different VLAN?

Hi Everyone,

I understand that I should keep the communication between the switcher (ATEM M/E 2 4K Production) and hardware panel (ATEM Broadcast Panel) segregated on its own network, the problem is I'd really like to be able to access the switcher from anywhere on our corporate network. When moving these devices to a "somewhat" dedicated VLAN within the corporate network segments, I notice that the hardware panel will somtimes lose connectivity with the switcher.

Has anyone experienced similar? This has been a couple of software releases prior when I experienced this behavior but losing connectivity is something we "obviously" can't have.

I think, a VLAN envirnoment is not typical for ATEM users. So I would suggest to ask some network professionals for possible issues.

By the way, switching makes only sense with knowing what happens on“stage“.So how do you want to transmit the preview with near zero delay at your network ?

What is your use case ?

my engineering network with ATEM and other device control has always resided on a VLAN in a managed switch network. If it's losing connectivity then you probably have a bad connection somewhere, or your VLAN perhaps has some rules in the switch (QOS or something) that could briefly halt packets to your ATEM in favor of other traffic. The ATEM passes a lot of data between switcher and panel, it doesn't take much of an interruption to knock it off line. just because you are in a VLAN doesn't ensure you get continuous and prioritized data-unless you have setup the switch with this in mind.

for what it's with, I run all of our pre-4k switchers on ver 6.9, and using 7.5 on all 4k models. haven't seen any significant issues with either of these versions (thankfully)

I really suggest the use of a Vlan for the Atem communication. Otherwise ALL computers in the network get 20 UDP data packets every second!! Lots of traffic..

But you might look at rulles for QoS or Vlan priority.. As said above.. A little hold up is enough to push it in to disconnect.

I really suggest the use of a Vlan for the Atem communication. Otherwise ALL computers in the network get 20 UDP data packets every second!! Lots of traffic..

No that is not true. The ATEM uses an unicast UDP protocol. So only the devices communicating with the ATEM receive (little) traffic. That should be no problem to be handled even for very low bandwith connections. But for security reasons it is a good idea to separate the network by using VLANs. The ATEM communications even passes subnets throught the gateways, routers and firewalls. No problem if configured correctly.

I have had no end of trouble with BM devices (ATEMs, Hubs, etc.) on defined VLANs. Very odd issues, where ATEM receives DHCP response as requested only fail to honor it and default to a self-assigned IP address. The VERY second, I remove the VLAN specification on the switch port, so that the switch port is ONLY presenting the physical network, no VLAN tagging at all, the BM devices start working, connecting as expected.

Get this... with VLAN tagging enabled, i.e. native VLAN assignment on connected switch port, on Ubiquiti network components, if I do static assignment, on the BM devices, they will connect, I can ping them, see them in the network monitoring views, but do they work right? No the ATEM will refuse to route to the assigned (VLAN) gateway, thus never cross over to the internet, never streaming say to youtube. I can remove the cable plug it into any other device, PC, for example, everything works, DHCP and internet access. I then return the cable to the ATEM, reboot the ATEM... and BOOM... back to self-assigned IP address. I remove the VLAN tagging/VLAN configuration on switch port, reboot the ATEM, and all is working. So the bottomline is, something in how BM implements they DHCP handling is a bit off, and VLAN tagging seems to trigger it.

If any other device did not work as expected, I would not point to BM as having issues, but it is only the BM devices that seem to get 'confused' by the VLANs. Sorry if any disagree, but that has been my experience thus far, and it is consistent and repeatable. Frankly, I think so few customers have (more advanced network designs than) a simple LAN configuration, that this issue is flying under the RADAR a bit.