It’s hard to rely on something you don’t know how to fix. On this week’s show, guest Alesia Hendley will help walk us through the tools and techniques for troubleshooting the network in an AV-over-IP system. We’ll touch on Wireshark, IP mapping, and discover the number one cause of network failure.

Episode guest

Alesia Hendley
Sales Engineer, Multimedia Journalist, Content Creator

Alesia has played many roles in her young pro AV career – end user, integrator, designer, sales, and even been a member of the press. She told us “really early in my career I noticed that every piece of AV equipment was connected to the network, so I thought hmm, I better learn about networks!” She has settled into a groove in sales engineering for Access Networks, so it’s her job to help ensure customer success by making sure the right pieces of the network are in place.

Episode transcript

Justin Kennington (00:10):

Hello, and welcome to SDVoE LIVE! I’m your host, Justin Kennington, and this is TV for pro AV. We have another exciting episode for you today entitled, “It’s 1:00 PM, Do You Know Where Your Network Is?”.

More and more AV systems, of course, are moved onto the IT network today, and that comes with it its own new set of challenges. Twenty years ago, when the screen went black, we knew where to troubleshoot Ww knew where to check. We knew where to find these problems. Now, that not only is control on the network but audio, and video itself, moves across the network. What are the tools, and techniques that are available for us to be able to troubleshoot problems as they come up?

Our special guest today is, Alesia Hendley. She’s a network engineer, and also does a lot of interesting work in the media space in AV, so we’re going to chat with her about some of her experiences troubleshooting networks.

We’re also going to introduce my co-host, Matt Dodd, who will show you a little preview of some SDVoE Academy courses on the subject of network troubleshooting. But before we get to that, I want to let you know that this is our very first broadcast that’s coming to you live not only inside SDVoE Academy, but also live on Twitter. And for the first time we are live on YouTube. So those of you joining us on YouTube live today, hello and welcome. I want to make the note that we will have an aftershow, after the 30 minutes of programming is finished so stick around if you’re here with us in SDVoE Academy. If you’re on YouTube or Twitter, make sure you make your way to SDVoE Academy when the credits roll, and you’ll be able to watch the aftershow there too. That is where we will answer your questions live.

If you’re in the academy, just look for the chat box or find us on Twitter at hashtag #sdvoelive with all of that out of the way, and without further ado, I’m going to hand this off to Matt, over in our classroom, who’s going to show you a little bit about network troubleshooting techniques.

Matt Dodd (02:48):

Hello everybody, it’s your favorite English chap here, Matt Dodd. Good to see you all. This is going to be a great show. Alesia’s fantastic. She’s really smart, she’s really cool, she’s just amazing so we’re going to have a lot of fun chatting away to her.  Before we do that, let’s take a little look at a snippet from two courses on SDVoE Academy – “Introduction to Network Troubleshooting – Part 1” and “Introduction to Network Troubleshooting – Part 2”.  You’ll like this one, it’s quite funny.

How many times have you taken a call from a client to tell you that something isn’t working? These calls can go one of two ways. It could go like this. Hello, Matt speaking.

Philip (03:55):

Hi, Matt. It’s Philip here.

Matt Dodd (03:57):

Hi, Philip.

Philip (03:57):

Are you well?

Matt Dodd (03:58):

Yes. Very well indeed, thank you.

Philip (03:59):

Excellent. I’m sorry to disturb you, but just having a few problems here. And I’m sure that it’s something silly, and more than likely something that we’ve actually done. Any chance you could swing by, take a quick look?

Matt Dodd (04:12):

Yes, of course.

Philip (04:12):

And then, hey, while you’re here, let’s pop out for lunch.

Matt Dodd (04:15):

Oh, wonderful.

Philip (04:15):

I’d be great to see you.

Matt Dodd (04:16):

Yes, and you.

Philip (04:18):

Sure. I’ll see you in a bit.

Matt Dodd (04:21):

But let’s face it, it rarely goes like that, because it usually goes like this. Hello, Matt speaking.

Philip (04:31):

Matt, Phillip here. Yes, nothing works, never has. Nothing’s ever worked since it was all put in. No, never, ever worked, very disappointed. And it’s the end of the world for us.

Matt Dodd (04:46):

This course will introduce you to the basic tools you need to equip yourself with before attempting any troubleshooting, as well as show you some common techniques, which help you to get to the root of the problems more efficiently. In the “Importance of Network Design” course, we identified the single biggest cause of network failure as being people. Now, this doesn’t mean we can automatically blame the customer for anything going wrong, especially on the network, but it does reinforce the importance of making sure the network, which you deploy your SDVoE system on, is thoroughly designed and documented.

Now that we’ve familiarized ourselves with a typical interface from the troubleshooting software, let’s take a closer look at some of the most common network problems which can occur with video distribution, the first being a network loop.

SDVoE receivers often include a one-gig network port for attaching other devices. Now, if this port is somehow connected back into the switch, a network loop will be introduced, and that’ll shut the entire network down. Remember the one-gig LAN port is designed to be a useful utility to connect hosts locally adjacent to the receiver, but under absolutely no circumstances must this port be connected back into the same network that is providing the string. If the network appears to be frozen, disconnect anything connected to the 1G ports, and if everything comes back online, the problem points to a network loop. The next issue that you might face is devices not being detected on your network. You open the control software after pairing everything up, but some devices are not registered in the API as expected, which means they aren’t showing up on the user interface.

Justin Kennington (07:13):

The phone call bit, that piece cracks me up every time. I’m sure we’ve all gotten that phone call from the highly reasonable, highly under control customer whose network is broken, and has nothing bad to say about you at all for it.

Matt Dodd (07:30):

I’ve had both of those customers.

How’s things been for you this last couple of weeks? We have a great show tonight, I’m really looking forward to it actually, Alesia’s really cool.

Justin Kennington (08:05):

Yes, for sure, and I think that the topic of network troubleshooting is a hot one. It’s a lot of what drives the AV professionals reticence around AV over IP as well. Am I going to be okay if something goes wrong? Am I going to know what to do?

Matt Dodd (08:24):

Shall we get on with some news? This is a great piece. I’ve got two little kids, you’ve got three little kids. What do my kids teach me about IT? Where do we start? We could talk about this for a long time, but my son is four years old and he is absolutely proficient at using an iPad. He’s all over it, at four years old.

As a guy who create educational videos, this warms me a little bit. As long as we moderate what he’s watching, then he’s actually learning some really good content, and it’s helping him to progress in school. He’s getting familiarized with the panels, or touch panels and we make a point of talking about how it’s made, the technology behind it, and he’s always interested. How about you? What do you take away from this? And how’s it for you with your little ones?

Justin Kennington (09:50):

What my little kids taught me about IT is to keep the IT locked away until after bedtime for simplicity’s sake. What I noticed in the article is the author said one of his children has autism and he has to think about how to communicate with someone that communicates in a very different way than is natural, and comfortable to the father. That drew a little bit of an analogy to how AV can interact with IT, but the father and his son are both humans. They both have brains. They just think and communicate in a little bit different way, and that’s the same story with AV and IT. We’re two sides of the same coin, but communicate with different vocabularies, with different language. Being able to be the person that bridges the gap between those two is extremely valuable, obviously in a parenting relationship, but in a professional context where you need to merge these two technologies. I thought that was the best analogy of the piece.

Matt Dodd (11:08):

Next up is an article entitled “AV Is IT”

Justin Kennington (11:50):

It’s a challenging statement to make. Scott Tiner, who wrote the piece, said to himself, well, of course, AV is IT, but why would anyone think that it’s not? He pointed to a history of how AV relates to IT. AV feels disrespected by IT. Oh, that’s just the AV junk, and we’ve got this high-end IT equipment. But as Scott points out, and I really agree, I think a lot of that has gone away, and the right way to think about AV is what is IT? Information technology. And AV is just moving information in a certain way through audio, and video signals.

So for me, it’s important to understand that the AV industry is an outgrowth, or a subsection of information technology. We’re the folks who are experts in presentation on screens, and in an auditory environment, experts on the user experiences created by those things. Whether that means a fancy augmented reality rollercoaster, or just a really nice, easy to use conference room.

Matt Dodd (13:09):

That sounds good.

Justin Kennington (13:09):

But I don’t think there’s anything wrong with calling AV a part of IT. I think it’s important to understand that they’re related.

Matt Dodd (13:18):

Just to further add to that, Scott makes some great points in his piece. It all boils back to education, and we’re doing a great job here in the SDVoE Alliance to really help people close that knowledge gap between what they’ve been comfortable with in AV traditionally and the move into what we call IT and data networks. Whether we like it or not, AV is IT, and that’s the way it’s moving forward.

So talking of moving forward and what a great segue, Justin, tell me who this lady is? Introduce our guest before we bring her in.

Justin Kennington (14:09):

Alesia is someone I met maybe two years ago. She works not only as a network engineer, but also as a journalist, and was writing a piece related to AV and IT, and interviewed me, and we had such a fun time talking. We’ve kept in touch ever since, and when we decided to put the show on, I knew she’d make a great guest with her background. I’m going to let her talk about it, I won’t give you her bio here. But her background is such a solid mix of AV and IT, specifically on the technical side, including network troubleshooting, and I thought she’d be perfect. There she is.

Matt Dodd (14:43):

There she is.

Justin Kennington (14:56):

Hey Alesia. Well, welcome. Thank you for joining us. I was just telling everybody out here that you had an interesting biography, that you’ve touched a lot of different pieces of the AV industry. So can you tell us a little bit about how you got here, and what you’re up to today?

Alesia Hendley (15:11):

For sure, it’s been an interesting ride. AV is constantly growing, technology is constantly growing. So a little background on myself. I started out in a house of worship as a sound girl, running audio. As that space grew, I grew with it, not only learning the audio side, but also learning the visuals that go into it from a very large production standpoint. Then I became an end-user within a pretty large venue facility to where I was running audio, lights, broadcast, software, all kinds of things, and a whole bunch of different venues under one roof, and I realized that all of my gear lived on a network.

When that transition came, it was an interesting pivot because our team was an AV in-house team, and the people who ran the network were over in another building. If the network went down, they would have to come over from wherever they’re at and come and help our team. So I realized learning about the network is ultimately another way to push my career forward, to today where I’m a sales engineer with Access Networks. And I joined this company because I wanted to be with a team that understood AV just as well as IT. This is a perfect place for me to marry these worlds and learn the language of IT that you and Matt were talking about earlier.

Justin Kennington (16:44):

So when you recognized that learning about the network is important, what did you do? How did you learn?

Alesia Hendley (16:52):

The first thing I did is figure out who was talking about this transition, whether that was at InfoComm or other tradeshows throughout the industry. When I first found AV as a whole, as far as an industry, there was a lot of talk of the convergence, and I was like, wait a second. The convergence is already here. My audio board has been on the network for three years now.

I realized that the debate you referred to in Scott’s piece, “AV Is IT” is an ongoing debate. I realized if I was going to continue to grow within my career, it was no longer a debate. It was time to learn the language, and make the pivot to marry these worlds together, because a lot of projects have both. You can’t have one and not the other, and ignore IT and love the AV, you have understand both of those. Even if you’re not the IT team, you have to understand the language so you can properly communicate with that team, in a talk about the problems that are happening in the environment.

Justin Kennington (18:02):

That’s a huge part of what we try to do in SDVoE Academy, just enable people to have that conversation. Not everyone has to be the certified network architect, but everyone has to know who the architect is, and how to have a productive conversation with that person, for sure.

Alesia Hendley (18:21):

That’s what I do in my day-to-day as a sales engineer because I get to work with all different facets of our team, but definitely being able to have those conversations with our network engineers, and understand what they’re saying, and relay it back to a client is super important.

Justin Kennington (18:41):

So in that sales engineer role on the network, your job, you tell me if I’m wrong, I’m going to put some words in your mouth, and you can agree to them, or spit them out. But I think your job is right there on the front end of finding out what are the customer’s ultimate needs, and then starting to piece together what are the technical aspects of that system that are going to make the customer’s needs happen? Is that a fair assessment?

Alesia Hendley (19:06):

Exactly. I’m beyond the sales team that’s bringing in the initial sale. I’m a part of the team that’s on that front line, where we talk about the technical specs of our products, and also educate about the technical specs of the products, because that’s most important. In the video I’ve watched from the SDVoE Academy, you break down that humans are the number one piece of the puzzle of network failure.

Justin Kennington (19:35):

We weren’t referring to sales engineers, of course.

Alesia Hendley (19:38):

No, but it’s true. You have to have that middle person there, to describe the design, how things work, and make it a “before thought”, if that is actually a word, “before thought”, and not an afterthought. When you have that strong core network, you can build the AV on top of that, and have a seamless communication between all of your gear.

Justin Kennington (20:00):

This is something that I know Matt emphasizes in a lot of our networking curriculum here. the fact that designing the network upfront is the first and most important step in not having problems later. So I think the fact that your role even exists reinforces that point.

Alesia Hendley (20:20):

100%. Usually when I was having trouble, it was because we didn’t design the network beforehand. It was an afterthought, and then we realized things weren’t working because we didn’t have the proper switches, or proper bandwidth, so it all plays into it

Justin Kennington (20:37):

Any specific war story around that idea? Or something that’s gone wrong with the network that you’ve had to scramble and fix before?

Alesia Hendley (20:45):

Oh, plenty of times, especially in my role as an end-user. All of our soundboards are on the network, and then all of a sudden you realize your internet is out because your board just locks up. You’re like, what is happening? And then you realize when you pull back the veil of what’s going on behind the switch, do we have enough bandwidth? Do we have enough power? Did we run an Ethernet cable that’s too long? All of these things came into play, but I’ve had lots of times where we ran cable that was too long, or also it’s PTZ cameras, we had a switch that didn’t have enough PoE budget. So there’s always a lot of things that played into the space. One thing was, I tried to always focus on with signal flow, just like a specialized audio person, or a specialized video person. There is signal flow, and there’s no difference when it comes to the IT side of our systems.

Justin Kennington (21:53):

Interesting. So what are some of the tools and techniques when something goes wrong? What’s the first thing you do when you realize the network is down? How do you start the troubleshooting process?

Alesia Hendley (22:07):

Well, we call the IT team. No, I’m just kidding.

Justin Kennington (22:09):

Well, that’s another important thing, is have their phone number.

Alesia Hendley (22:18):

In the past, as an end-user running into these situations, we always figure out, look at the software, especially I was mostly familiar with Dante. In situations like that it’s very important to make sure things are routed properly, and rehearsals are super important as everybody knows, especially when you’re bringing the IT side of it into your environment. Make sure things work ahead of time and not just in a live environment, whether it’s a conference room, just make sure it works ahead of time and make sure the network was designed to properly be a strong foundation for whatever systems you’re installing.

Also within my new role at Access Networks, when I first started, I didn’t really have the background from the IT side, so I would get with my guru, his name is Nathan Holmes. And one thing he asked me when we were troubleshooting switches and stuff, he’s like, do you have Wireshark? And I was like, what’s Wireshark? And that was a tool that just helps you find your IP addresses, so that’s a very helpful tool. And it has been as I continue to build my knowledge within the IT space.

Justin Kennington (23:27):

You may have even seen it pop up in the preview video Matt showed us before. There was a little Wireshark snippet, and in the longer videos he gets into that a little bit more. So everybody check out the courses on SDVoE Academy – “Introduction to Network Troubleshooting – Part 1” and “Introduction to Network Troubleshooting – Part 2”.

Alesia, that’s everything I have for you right now, but stick around because we’re going to have you back for the aftershow, where we’re going to hear from the audience and hear what they think, hear if they’ve ever had a network go down. I’m sure that you’re the only one here that’s ever had that happen. The rest of us are well-trained network experts that would never happen to. So I’ll say goodbye for now, but we’ll see you in just a few minutes.

Matt Dodd (26:19):

Hashtag #sdvoelive for all of your Twitter comments, please.

What will we talking about next in Episode 10 – “Network Safety for AV Pros”?

Justin Kennington (26:49):

Our guest will be Josh Srago. I’ve started calling him the JD for AV as he’s gone and got himself a law degree to become an expert on issues of security and privacy surrounding AV.