Go back

Why Faulty Clock Technology Should Be a Warning for Network Engineers

by kelly.yue Mar 6, 2017

It’s no secret that networks have grown incredibly complex and managing them has turned into a painful task. With the growth of transformational technologies such as software-defined networking (SDN), the Internet of Things (IoT), cloud computing and more, companies are being forced to manage networks that look very different from a decade ago.

Today, everything from coffeemakers to TVs have an IP address. The underlying physical and virtual networks are experiencing a rapid increase in the number of endpoints, changing traffic patterns, greater bandwidth requirements and more.

To manage networks with this level of scale, end-to-end visibility is imperative. Network teams need to be able to see what’s happening in the network in order to troubleshoot effectively. When an incident occurs and impacts the network, like the recent faulty clock components affecting Cisco, Juniper and HPE products, every second counts in getting the network back up and running. Everyone has seen the statistics on the costs of network downtime—a  $700 billion a year problem is not an inconvenience, it’s a critical business priority. Unfortunately, many organizations have yet to realize that the traditional ways of solving these problems are contributing in a significant way to that $700 billion figure.

Cisco Clock Chip Issue

For instance, when it comes to network diagramming, processes today are tedious, time-consuming, and expensive—whether it’s accessing the network device-by-device through command line interface (CLI) or manually generating diagrams with Microsoft Visio. With greater complexity, network engineers can no longer rely on static maps. It’s also becoming an unrealistic expectation for network engineers to keep network maps up to date.

Instead, network engineers should have the ability to create maps on-demand. Maps should provide rich details into the state of the network—configuration details, performance data, live status, and more—and automatically update themselves when the live network changes. These maps should also allow engineers to be able to quickly understand the exact path of network traffic when diagnosing problems. At NetBrain, we help engineers gain end-to-end visibility through the power of our Dynamic Network Maps.

Furthermore, when problems strike, many network teams rely on static playbooks—security checklists, design best practices, and troubleshooting guides—to implement policies and procedures. Unfortunately,  these reference documents can fall short as the network’s complexity evolves.  Automating these processes has become essential in saving valuable troubleshooting time.

Some key examples are when engineers need to troubleshoot recurring issues (e.g., link utilization, duplex mismatches, etc.), escalate problems across NOC teams, or deploy new technologies like QoS to the network. When it comes to new technologies, only select engineers who designed the solution or were trained have that troubleshooting know-how. With NetBrain, experts can now digitize their knowledge and best practices with Executable Runbooks. Runbooks are lightweight applications—that work on top of Dynamic Maps—that engineers can easily build and share with others. By automating network operations within executable Runbooks, organizations can reduce the over-reliance of tribal knowledge while building up a strong culture of collaborative diagnosis to fix network problems.

With end-to-end visibility and network automation, engineers can map live networks, easily map broken paths, run automated diagnoses, and efficiently collaborate with the rest of the team to fix issues. This saves valuable troubleshooting hours, and minimizes network downtime – protecting the bottom line.

Learn more about the value of end-to-end visibility and how it can speed diagnosis and troubleshooting of vulnerabilities like the clock chip issue our most recent webinar.

Related