In the past, we've written about the device inventory techniques. I've spoken about device configuration management. Here's a video of my talk on the subject. Eric Lavoie, another member of our senior staff, spoke to me recently about needing to make a small change on 81 voice gateways. He was shocked by my casual estimate of the amount of time required to write the code to collect, validate, and correct the configuration. He went back to his desk, convinced there was an easier way to make the change, and he found one!
Your companies telecommunications are only as good as your voice quality. Without good voice quality... well there's always email.
Sometimes after you've corrected QoS misconfigurations, validated WAN and LAN behavior and validated your fixes you still have user complaints. In this blog post, we dive deep into techniques that allow you to analyze and measure the behavior of the PSTN, beyond your SIP termination points and into the public phone networks. In this specific example even call recordings showed good voice quality. However, we established that the issues were related to call latency. Normally there is no way to measure latency without the use of specialized tooling, but we developed the following technique.
There are a number of factors that contribute to poor voice quality. In this article, we discuss methods to troubleshoot and isolate voice quality issues outside of the network and on the PSTN using packet captures and call recordings. Packet captures are one of the most powerful troubleshooting tools we have.
By now you've almost certainly heard about CVE-2018-0101, an unauthenticated, remote code execution vulnerability affecting Cisco ASAs. If you haven't, you should start planning to apply the update immediately to the ASAs in your environment. This vulnerability affects all ASAs that are configured to handle AnyConnect or clientless VPN connections. Some initial discussion in the security groups suggested that only clientless VPN was affected however this is not the case.
Few people would write up a security vulnerability 19 days after it was announced, but in the case of Spectre and Meltdown (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) each day that we've waited has brought new developments and additional information for us to consider, consolidate and present to our customers and blog community.
Readers who follow security news are already aware that the Spectre and Meltdown issues are substantial threats that have severe impacts on security. The vulnerabilities allow processes to read memory information that should not be accessible to them. User processes can access information from other processes and the kernel, in a virtualized environment they can also access information on the host and potentially other guests.
In a recent consulting engagement, our Professional Services team needed to help build a VPN connection between a series of Cisco Routers and a Google Cloud environment. We were surprised to discover that at the time we completed the project, Google did not provide a configuration guide for this common configuration type and wanted to share our experience building the connection. They have since added documentation for IKEv2 based ASR configurations. Our post highlights some important architectural details as well as the configuration requirements (tunnel mode, phase 2 timers) for the tunnels. It also makes use of an inner VRF, unlike Google's example.