Network testing is essential but sometimes challenging, and running into bugs and broken devices is a normal part of a test environment. But what happens when there are no bugs and the device isn't broken, but the test still doesn't work? Is it the test that is broken? Is the engineer to blame? Or is the problem something else, perhaps more subtle?
Strange or unanticipated testing issues happen all the time, and running a test network using IPv6 is no stranger to these issues. This handy list will go through some of the most common issues associated with IPv6 testing, as well as their potential resolutions.
1. Hardware: Does it have a link?
Sure, this is an obvious place to start and is not specific to IPv6, but it can be one of the most frustrating issues to try to hunt down, often because you just didn't think the cable was the problem. The truth is, cables slip, switches reboot, and sometimes hardware fails. All of these issues can cause a loss of communication at the most basic of hardware levels, and cause headaches for your testing. Speaking of switching, with the prevalence of wireless, virtualization, and even simple VLANs, hardware failures morph into a sight unseen, and can be even more troublesome to identify.
The best way around this problem is a stable, well labeled, and backed up (as in configuration) test network. A test network that changes rarely and is well known may not prevent failures, but will make it much easier to move through the weeds when problems do arise.
2. Firewalls: They exist!
Firewalls are evolving just as the IPv6 protocols are and are an absolute necessity when it comes to protecting users and software from malice. This means it is important to be aware of how the firewall is implemented, and what it is configured to monitor or block. Firewalls often block traffic that, while important for protocol test validation, can appear to be a denial-of-service (DoS) or another dangerous attack. An overly cautious firewall can make you wonder if you really are plugged in where you think you are, causing you to hunt down ghosts.
The resolution here is tricky. For testing, a disabled firewall can help narrow down the cause quickly. This doesn't help when it comes to deployment; then you must ensure that your device will behave on the Internet and protect its users. There is no silver bullet here; the best thing to do is to investigate why the firewall was blocking the protocol traffic and seek expert help to determine if this is an anomalous block or a true security vulnerability.
NEXT: Multihoming
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
