Video Transcript
Q-SYS Networking and Topologies (Part 3)
8m 20s
00:07
Let’s look first at a system using a single Q-SYS Core and Q-LAN network redundancy.
00:13
LAN A and LAN B are used for the respective primary and secondary networks.
00:18
Note the LAN B network is always ‘hot’ in the sense that Q-LAN is always flowing on both primary
00:25
and secondary networks to minimize any perceived audio losses when the primary network fails.
00:31
The Q-SYS network redundancy feature is designed to keep audio flowing
00:35
if there’s an Ethernet switch failure on the primary network.
00:39
That being said, the intention is not to plug LAN A and B networks into the same set of switches.
00:45
LAN A and LAN B should be connected to physically separate switched networks.
00:51
LAN A and LAN B network connections should be configured as separate IP subnets.
00:56
Each network should stand alone...there should be no connection between the two.
01:01
Q-SYS Core redundancy is fairly simple to plug in,
01:05
as in this diagram we see the LAN A connections of each Q-SYS device connected to the Q-LAN network.
01:11
LAN B is needed ONLY if a secondary network is being used.
01:15
Here’s a diagram of redundant Cores used in conjunction with network redundancy.
01:20
We simply add a secondary switch for the LAN B network. Remember, the previous rules still apply.
01:27
LAN A connections and LAN B connections should be configured as different subnets
01:31
and connected to physically separate switched networks that do not interconnect.
01:37
Q-SYS also supports peripheral device redundancy in certain cases.
01:42
Any required analog audio inputs and outputs, etc. would be paralleled
01:46
to both primary and secondary devices.
01:49
This is simple for devices using the relay switched inputs
01:52
and outputs on the CIML4 input card and the COL4 output card.
01:58
It’s also usable for analog outputs on the Core 110f and IO-8 Flex.
02:03
The input circuits on the 110f and IO8-Flex are not relay switched however,
02:09
so we do not recommend they be used for this purpose.
02:12
If you’ve looked carefully in Q-SYS software,
02:15
you may have noticed that there is no option for CXD-Q or CX-Q Series amplifier redundancy.
02:21
This is due to the need for switching the high-level loudspeaker line connections,
02:26
which can be electrically tricky.
02:28
If you have a project that requires networked amplifier redundancy,
02:31
please contact your local QSC applications team and they can make some suggestions.
02:36
As routers become more common in corporate networks,
02:39
we see more systems configured like this diagram.
02:43
First, let’s say if you’re designing a system and there’s no need for routing,
02:48
we’d recommend the simplicity of a switched network.
02:50
But, as a layer 3 protocol Q-LAN is routable. There are three major considerations:
02:57
The path from any Core to all destination peripherals
03:01
must have less than 280us latency for Q-LAN packets to arrive on time.
03:08
Proper QoS policies must be put into place on all segments of the wide area network.
03:14
Remember that Q-SYS relies on a multicast discovery method that allows peripherals to be discovered
03:20
and configured by the Core.
03:22
Q-LAN audio also relies on the multicast PTPv2 clocking mechanism.
03:27
These protocols require something called Protocol Independent Multicast routing,
03:33
or PIM, to be implemented in each router.
03:36
If all those conditions are met, Q-SYS should work perfectly on the wide area network.
03:43
We have one additional concern in this case with the device configurations themselves.
03:49
As we discussed in the previous lecture series, communication through a router requires a gateway.
03:54
The ‘Gateway’ entry as seen in the Q-SYS device configuration menus corresponds
03:59
to the ‘default gateway’ of the operating system.
04:02
This means there should be a total of ONE and ONLY ONE gateway defined across all interfaces.
04:10
The idea is that this gateway is used to route to all other subnets
04:14
unless the operating system tells otherwise.
04:16
The way we do this is through configuring something called static routes…
04:21
we tell the OS to use a specific alternate gateway to get to other specific subnets.
04:28
In the configuration example shown here, the Q-SYS Core will use the LAN A gateway 192.168.0.1
04:36
for ALL routes except the one defined in the static route for LAN B.
04:41
The static route defines the exception to use 192.168.1.1
04:47
as the gateway to the subnet 192.168.49.0/24 in CIDR notation.
04:54
We want to be particularly careful with this in Q-SYS configurations,
04:58
as we want Q-SYS to know exactly which NIC and which gateway
05:02
should be used to route the appropriate audio stream, etc.
05:06
A lesson learned from a large project site that required routing, and thus the creation of static routes.
05:12
The client configured subnets as shown in the table, counting up from LAN A to LAN B, etc.
05:18
With the even/odd subnet configurations of LAN A and LAN B of each device,
05:23
a static route had to be configured on every device to every other possible subnet.
05:29
The primary Core on the LAN A 192.168.0.0 subnet had to include a static route to subnets 192.168.0.2, 4, 6, etc.
05:42
The LAN B static routes had to be defined the same way.
05:45
The actual project was much bigger, which resulted in the definition of 48 static routes for each Core
05:51
on the wide area network, which resulted in hours of work.
05:55
The moral of the story is that all that work could be avoided just by adjusting the way
06:00
the device IP addresses were configured.
06:02
A static route can be defined to reach a range of subnets rather than just one.
06:08
Those rules work just like all the other rules for making subnets.
06:12
Recalling what we learned in the previous lectures (or using the online subnet calculator),
06:17
the subnet 192.168.0.1 with netmask of 255.255.255.240 has a host range from 192.168.0.0-192.168.0.15.
06:34
We can use that to define a single static route of all subnets
06:38
from 192.168.1.0 to 192.168.1.15 with a single definition.
06:46
If we observe the netmask of the static route, the first two 255s mean those octets must match,
06:52
or be composed of 192.168.something.something.
06:57
The 240 maps to 11110000, which implies a range of 0-15.
07:06
We can define a route to all those subnets by using a 255.255.240 in the static route netmask.
07:15
That’s a lot of numbers, so hopefully you’re hanging in there with me.
07:19
Now if I address all LAN A subnets in the range 192.168.0.0 to 192.168.15.0 and all LAN B subnets starting at 192.168.16.0,
07:35
I greatly reduce the work needed to configure the static routes.
07:39
In the project we mentioned before, this would have saved an entire day of typing in static routes!
07:45
If you didn’t get all that, don’t worry.
07:48
If there’s one thing to remember it's that if you have a situation like this,
07:52
don’t interweave IP address schemes for LAN A and LAN B.
07:56
Define all LAN A addresses by counting up, then come back around to LAN B
08:01
of the first device and go from there.
08:03
Ideally you’ll start the LAN B addresses on numbers that can easily be defined in a static route.
08:09
OK…if you haven’t yet experienced a cranial meltdown, now is the time to do it.
08:14
Let's take a break and then we'll move on to some lighter material
Downloads and Links
Q-SYS Networking and Topologies (Part 3)
8m 20s