Power Core node discovery across corporate networks
Power Core node discovery commonly uses multicast DNS (mDNS) so a console or control workstation can locate audio nodes without entering each address manually. A node advertises its service over UDP port 5353, usually through the IPv4 multicast group 224.0.0.251. This is a local broadcast-domain function, making it vulnerable to VLAN filtering, managed-switch behaviour, firewalls and enterprise Wi-Fi policies.
Many Australian broadcasters run production systems inside networks managed by corporate IT or a service provider. Studios in Sydney, Melbourne and Brisbane may use separate production, office and guest segments, while operators work from laptops that also carry VPN and virtualisation software. A sound diagnosis separates node health, IP reachability, multicast visibility and the discovery client’s network attachment.
| Symptom | Likely layer | First check |
|---|---|---|
| Node missing everywhere | Node power, addressing or node-side filtering | Power, cabling and direct Ethernet |
| Reachable by IP but absent from discovery | mDNS or VLAN path | UDP 5353, VLAN and firewall policy |
| Found on wired client but absent on Wi-Fi | Wireless policy or multicast handling | VLAN membership and client isolation |
| Found intermittently | IGMP state, VPN adapter or endpoint filter | Interface choice, querier and security logs |
| Discovered but no programme audio | Audio routing or control services | Stream route, QoS and control settings |
Understand the discovery boundary
Multicast DNS is a link-local service-discovery protocol, often associated with Bonjour-style browsing. Traffic normally stays within one broadcast domain; it is not repaired by asking a public DNS server to resolve a node name. A node can therefore be perfectly healthy, respond at its management address and still remain invisible to a console on another VLAN.
Audio streaming, control messages and clock synchronisation use their own traffic paths and ports. That distinction remains important in Ruby, VisTool and broader Broadcast 3.0 workflows: keep service discovery separate from transport checks.
Confirm the node is online
Begin at the node itself. Check its link lights, power state, boot sequence, management address and any hardware or software alarm. Where possible, connect a known-good controller directly by Ethernet and confirm the expected node appears. This fair-dinkum sanity check removes Wi-Fi, VPN and switch complexity before deeper packet tracing.
Next, compare the node’s stored address information with the control workstation. Duplicate IP addresses, an unintended interface or a subnet change can prevent a clean advertisement or make the client inspect the wrong adapter. Record the Power Core software and firmware versions, then compare those with the release notes and support guidance for the product.
Trace the multicast path
Capture traffic at the discovery workstation with a filter for UDP port 5353. A query without a reply places suspicion on the node-side VLAN or a firewall; a reply that the application ignores points towards adapter selection or endpoint security. The same capture also shows whether IPv6 traffic to ff02::fb is involved, an easy detail to overlook on dual-stack corporate networks.
Ask the network owner to check IGMP snooping, the querier, multicast ACLs and any firewall rule that filters 224.0.0.0/4. Snooping without a suitable querier can prune multicast memberships, while an approved mDNS reflector or gateway can bridge selected segments. Do not disable snooping or open multicast broadly as a first move; both changes need a controlled test and security approval.
Test Wi-Fi, VPN and virtual adapters
Enterprise Wi-Fi often adds client isolation, guest-network restrictions and multicast optimisation. A console can have a valid IP address yet receive no multicast from the studio VLAN. Compare a wired station with the affected wireless one, inspect the access-point controller and confirm that both endpoints are placed in the intended VLAN. Australian offices commonly use WPA-Enterprise with RADIUS, so the credential is only one part of the policy.
VPN, VDI, Hyper-V and VMware adapters can also claim the route or multicast membership expected by the application. Temporarily disable unused adapters on a test system and verify the active Ethernet or Wi-Fi interface. Live entertainment offers a useful parallel: Lawo’s live casino technology example shows another tightly controlled environment where predictable network behaviour matters.
Remove endpoint and software interference
Host firewalls, endpoint-protection suites and VPN clients may block UDP 5353 even when corporate rules allow it. Check Windows Firewall profiles, third-party security logs and application-control policies, then repeat the capture with the controller running as an administrator only where this is an approved diagnostic step. The test should distinguish a blocked packet from a packet the application never requests.
On the node, verify that it publishes the expected discovery response on the active interface. Review firmware notes for known mDNS fixes, and avoid changing network identity, hostname or clock settings without checking the release documentation. Lawo support can confirm the intended control workflow for the installed Power Core generation.
Establish a controlled fallback
If isolation is intentional, keep it. A sustainable design can use an approved mDNS reflector or gateway between selected studio VLANs, with rules limited to the required service and destination. If the control client supports manual node entries, a fixed management address can restore administration while the permanent multicast design is prepared; audio and control routes still require separate validation.
Regional Australian operations add a useful constraint. Radio stations and mine sites around Perth and Queensland often depend on leased links, satellite or 4G/5G for support, and mDNS should not be tunnelled indiscriminately across those links. Managed service providers and local integrators can implement a narrow, documented exception rather than a broad rule that later becomes hard to audit.
Keep the evidence with the fix
Document the topology, node and client addresses, VLAN IDs, switch ports, firewall rules, captures and the final change owner. In a market where broadcast engineers and enterprise IT teams share responsibility, this record prevents the same discovery fault from being rediscovered after a workstation replacement or a new broadband service is installed.
The lasting rule is that a visible Power Core node is the result of a working local multicast path, not merely a reachable IP address. Keep discovery traffic inside the approved broadcast domain, make each exception explicit and preserve the evidence so future support shifts can reproduce the diagnosis instead of relying on guesswork.
