Q-SYS Networking and Topologies (Part 3)

Let’s look first at a system using a single Q-SYS Core and Q-LAN network redundancy.

LAN A and LAN B are used for the respective primary and secondary networks.

Note the LAN B network is always ‘hot’ in the sense that Q-LAN is always flowing on both primary

and secondary networks to minimize any perceived audio losses when the primary network fails.

The Q-SYS network redundancy feature is designed to keep audio flowing

if there’s an Ethernet switch failure on the primary network.

That being said, the intention is not to plug LAN A and B networks into the same set of switches.

LAN A and LAN B should be connected to physically separate switched networks.

LAN A and LAN B network connections should be configured as separate IP subnets.

Each network should stand alone...there should be no connection between the two.

Q-SYS Core redundancy is fairly simple to plug in,

as in this diagram we see the LAN A connections of each Q-SYS device connected to the Q-LAN network.

LAN B is needed ONLY if a secondary network is being used.

Here’s a diagram of redundant Cores used in conjunction with network redundancy.

We simply add a secondary switch for the LAN B network. Remember, the previous rules still apply.

LAN A connections and LAN B connections should be configured as different subnets

and connected to physically separate switched networks that do not interconnect.

Q-SYS also supports peripheral device redundancy in certain cases.

Any required analog audio inputs and outputs, etc. would be paralleled

to both primary and secondary devices.

This is simple for devices using the relay switched inputs

and outputs on the CIML4 input card and the COL4 output card.

It’s also usable for analog outputs on the Core 110f and IO-8 Flex.

The input circuits on the 110f and IO8-Flex are not relay switched however,

so we do not recommend they be used for this purpose.

If you’ve looked carefully in Q-SYS software,

you may have noticed that there is no option for CXD-Q or CX-Q Series amplifier redundancy.

This is due to the need for switching the high-level loudspeaker line connections,

which can be electrically tricky.

If you have a project that requires networked amplifier redundancy,

please contact your local QSC applications team and they can make some suggestions.

As routers become more common in corporate networks,

we see more systems configured like this diagram.

First, let’s say if you’re designing a system and there’s no need for routing,

we’d recommend the simplicity of a switched network.

But, as a layer 3 protocol Q-LAN is routable. There are three major considerations:

The path from any Core to all destination peripherals

must have less than 280us latency for Q-LAN packets to arrive on time.

Proper QoS policies must be put into place on all segments of the wide area network.

Remember that Q-SYS relies on a multicast discovery method that allows peripherals to be discovered

and configured by the Core.

Q-LAN audio also relies on the multicast PTPv2 clocking mechanism.

These protocols require something called Protocol Independent Multicast routing,

or PIM, to be implemented in each router.

If all those conditions are met, Q-SYS should work perfectly on the wide area network.

We have one additional concern in this case with the device configurations themselves.

As we discussed in the previous lecture series, communication through a router requires a gateway.

The ‘Gateway’ entry as seen in the Q-SYS device configuration menus corresponds

to the ‘default gateway’ of the operating system.

This means there should be a total of ONE and ONLY ONE gateway defined across all interfaces.

The idea is that this gateway is used to route to all other subnets

unless the operating system tells otherwise.

The way we do this is through configuring something called static routes…

we tell the OS to use a specific alternate gateway to get to other specific subnets.

In the configuration example shown here, the Q-SYS Core will use the LAN A gateway 192.168.0.1

for ALL routes except the one defined in the static route for LAN B.

The static route defines the exception to use 192.168.1.1

as the gateway to the subnet 192.168.49.0/24 in CIDR notation.

We want to be particularly careful with this in Q-SYS configurations,

as we want Q-SYS to know exactly which NIC and which gateway

should be used to route the appropriate audio stream, etc.

A lesson learned from a large project site that required routing, and thus the creation of static routes.

The client configured subnets as shown in the table, counting up from LAN A to LAN B, etc.

With the even/odd subnet configurations of LAN A and LAN B of each device,

a static route had to be configured on every device to every other possible subnet.

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.

The LAN B static routes had to be defined the same way.

The actual project was much bigger, which resulted in the definition of 48 static routes for each Core

on the wide area network, which resulted in hours of work.

The moral of the story is that all that work could be avoided just by adjusting the way

the device IP addresses were configured.

A static route can be defined to reach a range of subnets rather than just one.

Those rules work just like all the other rules for making subnets.

Recalling what we learned in the previous lectures (or using the online subnet calculator),

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.

We can use that to define a single static route of all subnets

from 192.168.1.0 to 192.168.1.15 with a single definition.

If we observe the netmask of the static route, the first two 255s mean those octets must match,

or be composed of 192.168.something.something.

The 240 maps to 11110000, which implies a range of 0-15.

We can define a route to all those subnets by using a 255.255.240 in the static route netmask.

That’s a lot of numbers, so hopefully you’re hanging in there with me.

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,

I greatly reduce the work needed to configure the static routes.

In the project we mentioned before, this would have saved an entire day of typing in static routes!

If you didn’t get all that, don’t worry.

If there’s one thing to remember it's that if you have a situation like this,

don’t interweave IP address schemes for LAN A and LAN B.

Define all LAN A addresses by counting up, then come back around to LAN B

of the first device and go from there.

Ideally you’ll start the LAN B addresses on numbers that can easily be defined in a static route.

OK…if you haven’t yet experienced a cranial meltdown, now is the time to do it.

Let's take a break and then we'll move on to some lighter material