You’ve been doing networking for a long time, and you know that every additional layer makes troubleshooting harder.
- Extending Layer 2 private networks with VXLAN and finding out that your toolkits don’t span both the underlay and overlay networks
- Overprovisioning the physical network to try to maintain acceptable performance
- No more quick fixes like unplugging a redundant switch like you did with spanning tree loops
Fault isolation is incredibly hard without visibility across the potential problem space. Since most legacy networking tools rely on SNMP, maybe you’ve pulled in a new tool for the Nexus 9000 NX-API. The VMware team sees part of the story in their private networks in NSX Manager and vCenter, and the ACI team has a good idea about the spine and leaf network from the APICs.
Let’s not even talk about the horrible experience with that log consolidation tool that didn’t even understand that private networks have overlapping IP addresses.
Buying, installing and patching all those tools while building and maintaining expertise is hard and expensive.
Worse, even with all these tools, you still get surprised by performance degradation, outages, maybe even devices that suddenly disappear from the network.
The Dream: Correlation Between Overlay Traffic and Underlay Transport Paths
That’s the kind of dream that only network managers have!
There’s no magic here, you just need visibility to the traffic in a tunnel, to measure the performance on a virtual circuit and interface just like you do on physical devices, and to understand exactly what underlying physical circuits are supporting each overlay network.
A coordinated end-to-end view across virtual and logical networks cuts problem diagnosis time in half, and that directly maps to increased uptime. Better, it can help you find problems before anyone is affected.
A Holistic Approach to Overlay Networking
Zenoss builds and automatically maintains a real-time model of your entire overlay/underlay network that identifies all the physical (Layer 2), logical (Layer 3) and virtual (VLAN, VXLAN, MPLS, NSX, ACI) relationships and dependencies.
With the model, you can examine an application to see how its VLANs perform, identify hot spots or failures in the specific physical switches the VLANs depend on, and determine whether networking, virtualization, storage, even server hardware failures are present.
You don’t have to plan ahead, either. You can build an application-specific view of the model in a couple minutes from the UI just by adding the top-level operating systems and VLANs. You don’t have to build the connections in a CMDB ahead of time or spend hours in a proprietary programming language developing rules.
Quit struggling with overlay/underlay network outages. We can show you a better way.
