In my ongoing series of networking concepts in AVL systems (visit the archive here), we’ve spent most of our time focusing on technical concepts like VLANs, IP addresses, Wi-Fi design, and other aspects such as the OSI model.
Now that we’ve learned some of the fundamental concepts and have started dabbling in a little bit of configuration, we’re going to take a little detour and talk about documentation and keeping your network configurations organized, along with some tips on implementation.
I can’t tell you the number of times I’ve showed up to troubleshoot networks in AVL systems at churches and other venues or showed up to a load-in for an event and had to spend an insane amount of time just figuring out how the network is set up before getting everything up and running.
I often get calls to help solve a problem, show up, and nobody knows the IP address or login credentials of the network switch that needs to be fixed, or even a list of which ports on which switches are assigned to which VLANs. That can get pretty important and take a lot of time to figure out and can get pretty stressful when you’re in emergency mode! This is where we have a conversation about documentation.
Documenting your networks (and honestly, the rest of your AVL systems with Dante patching, stage input lists, monitor mixes, DMX channels. etc.,) isn’t the most glamorous part of the job, but is one of the most important. Here we’ll focus on networks, but maybe it’ll jog your mind on ways to document the rest of your systems.
Before diving in, I should note that there are many ways to do this. If you feel overwhelmed, don’t worry about it. Doing something is better than nothing. Document it the best you can so at least you can look back and remember how things are set up or help explain to someone else who comes to help troubleshoot.
You can easily change how you do your documentation as your systems and needs change. I’ll share some tips on how I do things, and if you have any cool ideas, go for it and let me know how it goes!
You probably have a handful of accounts and passwords for things used in your AV system. ProPresenter accounts, streaming platforms, Dante Virtual Soundcard licenses, Waves, Wi-Fi and router passwords, iPads, computers for multitracking, and so on. It’s easy to start making up passwords and the have it get away from you pretty quickly.
Maybe you post sticky notes or labels on your devices with their passwords or keep them on a sheet of paper in a drawer somewhere, or they’re all in someone’s brain as some Bible verse quote and you text it to someone.
When a password doesn’t work, you suggest “Eh, it’s something like that. Try it with capital letters, or with a 1 instead of an I or something.” Not the most efficient or secure metholdology.
Password security is important. Almost every solution has some sort of downside to it in one way or another, but almost anything is better than the sticky note or use-the-same-credentials-everywhere method.
I’m a fan of password managers such as Lastpass and 1Password. Essentially, you install their utility in your web browser, or install their app on your phone, and it stores all your accounts and passwords and automatically fills them in, or lets you search for them to copy and paste or enter in your device.
Password managers can also store secure notes and other information. Obviously one of the biggest criticisms of tools like this is if someone gets into your password manager account, they can get into everything. While that’s true and there’s no such thing as a zero-risk solution, I think the risks are more than outweighed by the benefits.
With a password manager, you can easily create ridiculously complicated passwords that are unlikely to be cracked, and it can store them and fill them in. (Honestly, I don’t even know most of my passwords, my password manager just created them and fills them in.)
You can also use these tools to share passwords with others, so if each person on your team has an account, you can share folders of passwords with the people who need them, like your AVL team. We won’t go much further into that topic, but it’s worth being aware of that possibility and looking at different products to see how they might help in your workflow.
In Part 4 of this series, I discussed IP addressing. You may remember reading about IP addresses, Subnet masks, and gateways/routers, and DHCP servers. For a recap, go glance over that article. It will be helpful to have a basic grasp of those concepts before we dig into this more.
Documenting our IP addresses and network information can be done pretty simply. It’s easy for IP addresses to get out of control and sloppy. Because they need to be unique to one device on your network, they need to be documented to make sure we don’t end up assigning the same IP address to multiple things. It can also help us keep track of things like what our DHCP range is, default gateway/router is, DNS servers, VLAN numbers, and so on.
There are some great and expensive products for documenting large networks that I’ve used, but for most cases, a simple spreadsheet is going to be perfect. In order to not have multiple copies and versions floating around, it’s going to be best to have it in a centralized and shared location where everyone who needs it can access the same copy.
So rather than having it on multiple computer desktops, if your organization is using Google Workspace or Microsoft Office 365, create a spreadsheet and share it with the people who need it. That way, everyone’s working off of the same updated document and you can share with anybody who might need it.
Figure 1 is an example of a spreadsheet for documenting IP addresses. The basic network information is in the top portion and a column of the IP addresses of the subnet where we can fill in the slots as we add devices. If you want to create additional columns to include notes and other information, go ahead. This is just an idea to help you get started.
Inside of this same spreadsheet, we can make additional tabs for any other networks you have such as staff networks or AVL networks in other venues. Simply duplicate the sheet and make your modification. If you have a lot going on, you can make another sheet that has a list of VLANs being used and basic information about them.
As far as organizing your IP addresses, the number one rule is don’t use the same IP address on multiple devices on the same network, and don’t use the same subnet/IP address range on multiple networks in case you need to route them together. That said, there are a few things to do to keep things nice and tidy.
Most networks will be a /24, which is 255.255.255.0. This means that you’ll have 254 addresses available. (Look back to the previous article about IP addressing for a recap.) If you need more addresses than that, you can expand your subnet, but that’ll be pretty rare so we won’t go too far into that. Just know you aren’t limited to 254 addresses.
I like to segment out my IP address range before starting to assign addresses to see how everything will sit. I save a few IP addresses on the front and end of the subnet for IT related things: DHCP servers, switch management IPs, and other infrastructure things. It can be handy for IT folks to have a few for their things.
Then, I create segments for specific things like audio (which we can break down into ranges for consoles, amplifiers/speakers, wireless mics, etc.), video (where we’ll account for switchers, video routers, control surfaces, video recorders, etc.), and segments for computers and tablets. I figure out how many devices of each type that I expect to have on the network and then reserve segments in the subnet that have plenty of room to add more. So if there are six audio devices, I usually give it a range of 20 IPs before I start putting video devices on the spreadsheet.
Here’s where it might be helpful to touch up on using DHCP, which is how devices are assigned an IP address automatically when connecting to a network. This is standard for things like connecting a computer to Wi-Fi so you don’t have to manually assign IP addresses to the computer every time.
But in AVL systems, it can get pretty weird for a couple of reasons. First, you’re not guaranteed to keep the same IP address forever. So, if the video switcher is on DHCP and changes IP addresses, the switcher control surface might not be able to see it anymore without finding its new IP address to configure. Yes, it can be fixed by using DHCP reservations, which makes the DHCP server give the same IP address to a specific device each time, but that flows into the other consideration, which is reliability.
If you have any issues with the AVL switches uplinking to the church’s network and there are critical devices set to DHCP, they might not get IP addresses and not work at all. For that reason, I typically manually assign IP addresses to AVL equipment as much as possible. I’ve had cases where the core network infrastructure of a church has fully crashed, but our AVL systems continued to run normally because none of the equipment was dependent on the rest of the network for their basic operation.
You might also be running a simpler network that’s just a couple of network switches with devices connected to them with no uplinks to other networks or the internet; in that case you might not even have a DHCP server, so manually assigning IP addresses is the way to go.
All that said, DHCP still has its place. Band members bringing their own tablets to control their monitor mixes, connecting a laptop for troubleshooting, or other roles where static IP addresses aren’t critical. So, I also create a range for DHCP in my IP address spreadsheet.
Some best practices in DHCP include having at least double the number of IP addresses available in your DHCP scope than you plan to have in devices. In addition, you’ll also want to set DHCP to hand out IPs for a lease time of half of the average connection time for your users. Some equipment is set to a default of a week, which means that every time a device is connected, that IP address is tied up for a week before it can be reused. By setting it to half the time of the average connection time, that IP address isn’t tied up forever and can be assigned to another device if one shows up.