Dante Certification Level 2 – Chapter 14: Basic Troubleshooting

Level 2 – Chapter 14 – Basic Troubleshooting

What’s the first thing you do when someone calls and says it’s not working? Designing and building a system from the ground up is one thing, but troubleshooting a malfunctioning one, especially if someone else built it, can be far more challenging to make things even trickier. Imagine trying to diagnose the issue over a phone call or text message. In this chapter, we’ll introduce you to a basic structured approach to troubleshooting.

Some of these are strategies that apply to any technical issue while others focus specifically on diagnosing problems with Dante networks. In level one, we broke Dante down into four functional categories, connectivity, discovery, clocking, and subscriptions. We mentioned that these four categories along with the OSI model, are essential for troubleshooting problems, so now’s the time to do some demonstrations. I received a phone call from Rachel for an issue in a meeting room environment.

She asked if I could check the system and try to solve the problem. As you can see, we have a basic system consisting of two mixers, two microphones, two PTZ cameras, two encoders, two decoders, two speakers, and two AVOs spread across a pair of meeting rooms. Everything is connected to two switches and there’s an up link between them to share media between rooms. The first step in solving a problem is defining what the problem is and what the system is supposed to do.

Next, we want to establish a theory about what might be causing the problem. That includes making a list of the problems you find writing down a hypothesis about possible causes and brainstorming how to solve the problem. Finally, after all that, test it and if it works, great, but if it doesn’t start over in a more advanced troubleshooting scenario, we might use Wireshark or another packet analysis tool to help solve the problem. For now, let’s focus on layer one and layer two troubleshooting using Dante controller.

As you can see here, the problem is that not all the devices are being discovered in Dante controller and some devices appear in red according to Rachel. We need to discover devices in both rooms so that we can share audio and video from one room to the other. To to establish a theory, we might ask ourselves some questions. First, remember the four categories from earlier, connectivity, discovery, clocking, and subscriptions.

Let’s start with the first category, which is connectivity. We should ask ourselves, can Dante controller see the devices and can Dante devices discover each other? This is the most fundamental question. Devices that can’t see each other can’t elect a clock leader or establish subscriptions.

In our case, we already know the answer, right? It would be a big no or perhaps some of them. The question then becomes is this a physical issue or a logical one? Let’s start troubleshooting at the physical layer, which of course is layer one.

Physical issues pertain to hardware problems that can disrupt network connectivity. It is essential to check for network activity lights on both the devices and the switches to confirm connectivity. Basic troubleshooting includes ensuring the devices are powered on receiving adequate power over ethernet or POE and testing the network cable to make sure it’s functional. I know these sorts of troubleshooting steps seem rudimentary, but trust me, these types of problems often escape seasoned professionals who simply overthink the problem.

Other things to take a look at are the connections themselves. They should be properly secured as improperly fitted. Copper or fiber connectors can cause a physical gap that prevents communication. Additionally, oxidized or dirty connectors may interfere with signal transmission.

For software like Dante controller or Dante virtual sound card, verifying that the correct network interface is assigned is also important. Based on these steps, we can see that everything is powered on except for this PTZ camera. This camera receives power via POE, so there’s a chance that the switch isn’t providing enough power or maybe it’s just not plugged in correctly. If we check the switch again, we can see it wasn’t properly connected.

Once we plug it in correctly, it now appears in Dante controller. Sometimes Dante AV devices will show up in Dante controller, but when you try to send a video stream, it crashes. There could be several reasons for this, but one thing to check is whether the switch is providing enough power. For instance, You can physically connect a P OE plus plus device to a P OE plus switch, and the device might power up initially, but later it will require more power than the switch can deliver.

In that case, upgrading to a P OE plus plus switch or using a P OE plus plus injector might be necessary. Now that we’ve ensured that all devices are properly plugged into the switch, let’s check the connection between the two switches. This connection is made using a fiber optic cable. With SFP modules, even though both are connected, the switches can’t communicate with each other.

Let’s inspect the fiber cables and SFP modules. We notice that the cable is multi-mode fiber, but the SFP module is single mode. This is certainly the issue. Once we replace the SFPs with a matching multi-mode module, connectivity is established.

Another important thing to check is that the category cables are connected to the Dante primary ports. Since these meeting rooms don’t have a redundant network, the secondary port shouldn’t be used at all. After verifying, we see that the PTZ cameras, ENC coders, speakers, and microphones show up as expected. However, we still have issues with a few devices in Dante controller.

Under the device info tab, mixer A is highlighted in red and has a link local IP address in the primary address column while showing the correct IP in the secondary address column. If we double click the device, we see a message indicating that it has an address on its secondary interface that matches the subnet of the local Dante interface, which could be causing the issue. In this case, it’s clear that the cable is plugged into the secondary port instead of the primary. Sometimes other issues like incorrect cable connections, merged networks or misconfigured Dante controller nick settings could also cause this.

If a device has a screen, it might even indicate that it has switched to the secondary port. That can be really useful. The issue with mixer B is a bit trickier because it doesn’t appear in Dante controller at all. When we physically check the device, we see that the cable is connected to the control network port instead of the primary Dante port.

Once we plug it into the correct port, both mixers show up in Dante Controller as expected, but now we notice a decoder is appearing in red, so what’s next? All physical issues were properly solved, so now it’s time to take a look at the logical issues using the tools available to us in Dante controller. Logical issues focus more on network configuration and connectivity problems that may hinder device discovery and communication. Once the physical connection is confirmed, ensuring that the device is on the correct VLAN and subnet is necessary.

Issues such as IP address conflicts, improperly configured security settings or network restrictions from ACLS or IGMP snooping could impact functionality. Network security settings on a computer including firewalls may also block Dante traffic. Temporarily disabling firewalls or reinstalling. Dante controller can help determine if software related issues are causing disruptions.

At this point, we do still have an issue. Devices aren’t showing up on Rachel’s computer on mine. Some show up correctly. Well, two looks strange and another remains in red.

Let’s start by troubleshooting my computer. Before fixing Rachel’s talking to Rachel, she mentioned that she lent one of the decoders to someone in the company for use in another meeting space, and when she brought it back, it didn’t work. Let’s make an assumption here. What happens if someone changes the device’s IP addresses?

We have seen this kind of issue multiple times. Let’s suppose you are using A-D-H-C-P server in the office for these two meeting rooms and you correctly pre-program the decoder there. That means if someone else wanted to use that decoder in a different subnet, they’d either need a different DHCP server on a different range or they’d need to use a static IP address. In the best case scenario, they do nothing and remain in auto IP addressing, but in the worst case scenario, they’d have to assign a static IP address.

If they forget to leave the equipment exactly as they found it in DHCP, then obviously you’d have problems at the office once you put it back, right. To explain this, let’s use a diagram. Dante controller subscribes to multicast messages directly from devices, and since multicast traffic operates independently of subnet boundaries, unless this one is blocked, Dante devices can send discovery messages across the network even if subnet differences exist. In this case, we’ll receive discovery messages from the transmitter.

When we try to send a command like retrieving status information or creating a subscription, Dante controller uses unicast at this point. Subnet rules apply. Again, if the laptop detects that the decoders IP is on a different subnet, it will try to send data through the router. The router will search for the address on other VLANs won’t find it, and the connection will fail, but now we want to be able to send a command to that decoder perhaps to get more detailed status information or to create a subscription.

That command is going to be sent uncast. Now we’re back to following the rules of subnets. When the laptop sees the IP address of that decoder, it will determine that it’s not in the same subnet and it will send that to the router. The router will begin looking for that address on other VLANs.

It’ll be looking in the wrong place and it won’t complete the connection. To alert you to this issue, Dante controller will show the device in red, as we’ve said before, anytime Dante controller shows you a picture, a color or a graphic, it has a purpose. If you double click on the device in red like we did with the speaker earlier, Dante controller may be able to give us more information about this device. In this case, we can see it’s listing the subnet.

Okay, well, that’s helpful information. I could take my laptop, set it to a static IP in the same subnet as the decoder, and then make the changes to get everything back where it should be. I don’t have to worry about factory resetting everything and losing all my work, so let’s do that for my decoder. Once I double click on the device, I can see it is in the 1 9 2 1 6 8 100 0 slash 24 range.

I’ll set my computer to 1 9 2 1 6 8 100 200, and I will be able to see the decoder but not the other devices. Once I see it, I go to the device view network config tab and set it back to auto IP addressing because I have A-D-H-C-P server on the network after that that I put my computer settings back to the way they were and I will be able to see the decoder along with all the other devices on the network. Okay. Here’s another scenario that may happen to you.

What if everything is showing up red? Did you put every device in the wrong subnet? Well, I suppose that’s possible, but it’s more likely that your laptop is the one that’s in the wrong subnet. Since laptops move a lot, we often need to be at specific addresses.

When we’re commissioning a system, we may have forgotten to set our laptop back to DHCP. I think all these issues are all pretty straightforward. They are just simple mistakes that we make during commissioning that can be easily fixed. Finally, what happens if Dante controller can’t show you anything?

Just like what’s happening with Rachel’s computer? Well, this presents a challenge. The first step in troubleshooting would be to determine whether the issue originates from the laptop itself or from the network. Now that we’ve reached this point, let’s address the issue with Rachel’s computer.

The last time this happened, she simply closed and reopened Dante controller, and that resolved the issue. While we could try that again, our goal is to find the root cause, so we’ll take a deeper look. If you recall from our intermediate Dante controller chapter, there are various filters and settings that could provide insight. To start with the basics, we need to ensure that Dante controller is connected to the correct network port.

Sometimes it may be set to wifi when we’re expecting to use the wired connection. If this is my first time using this particular installation of Dante controller, or if this is a new computer, I’d compare it with a known working system. By connecting another computer to the network, we can determine whether the issue is with Rachel’s laptop or something else. If the second computer works fine, then the issue is isolated to Rachel’s computer.

The problem could be caused by active filters in Dante controller security software blocking access to certain ports or even something as simple as a reboot or reinstall of Dante controller on larger networks with more complex configurations. Another straightforward test is to connect directly to a Dante device. If the device has redundant network ports and the secondary port is available, we can set the device to switch mode and plug our laptop directly into the secondary port. This method still allows automatic IP configuration from the network while providing a direct connection to the Dante device, avoiding potential issues with network configuration.

If the device does not have redundant ports or requires POE, don’t worry. Using a small unmanaged switch can achieve the same result. This is why I always carry one in my troubleshooting kit. If a direct connection works, but a connection through the larger network fails, we know that both the Dante device and Rachel’s laptop are functioning correctly, meaning the issue lies within the broader network configuration.

Given that we are working in an enterprise environment, this could be the result of a configuration change either made by us or by an IT manager. Taking a closer look at the network view in Dante controller, we see that it shows only two out of 14 devices. In the device info tab, we confirm that only two devices are listed by going to the filter pane and selecting clear all the number of visible devices increases to 14, and they all appear in the device info tab. The final step is to remove any blank spaces from the filters in the routing tab.

Once we do that, they all appear generally blocked traffic is the result of some sort of network policy. A common cause could be IGMP snooping being enabled on the switches without configuring an IGMP query. In this case, the switches receive multicast traffic but hold it indefinitely because they never received the necessary subscription list. Another important factor is access control lists, also known as acls.

These restrict traffic based on MAC addresses, port numbers or other criteria. IT managers often use these lists to enhance network security. If this is your own network, you likely know what policies are in place. You can disable them one by one until the issue is resolved.

Once everything works correctly, you can reintroduce the policy step by step to identify the one causing the problem. However, if you are working within a networked managed by an IT department, you’ll need their assistance. In this case, it’s best to set up a meeting with the IT team rather than making an unscheduled request. Having documentation such as the Dante information for network administrator’s guide can help explain your concerns.

Approaching the conversation professionally and on their schedule will typically lead to a more cooperative response from the IT team. Finally, there is one last issue. To address the two AVOs appear with a number in brackets. This is most likely a duplicated device name to troubleshoot.

We can disconnect both devices and reconnect them one at a time. We’ll see that the number in the bracket disappears, so it is definitely a duplicated name. The solution would be to rename one of the devices and then reconnect the other A VO. Once completed, both AVOs appear correctly and Dante controller.

I hope this walkthrough has provided a helpful overview of basic network troubleshooting and common issues that may arise on Dante networks. You are nearing the end of level two. We’ll see you in the next chapter.