NetOps, AppOps and the Dance of the Pointing Finger
2020-05-21 | 6 min read
Quality of Service (QoS) and performance issues have been the bane of network administrators pretty much since the day after networks existed. First thing most organizations would do after being able to ping one site from another would be to try to run some sort of apps on that network. And that is where the fun would usually start.
You can almost imagine Sir David Attenborough of BBC nature documentary fame narrating:
In a scene as old as the Serengeti, we see here the network administrator resplendent in his mane-like unix beard and Spock t-shirt, starting to relax after a triumphant deployment. His momentary calm is not to last as a member of the database team, boasting a Twitch hoodie, makes her approach.
The hallowed and age old dance of finger pointing begins. The apps side asserts that users are reporting performance issues – the db is slow, laggy, unresponsive. The network side retorts with low ping times and plenty of available bandwidth….anyway, I am sure you get the picture. Indeed, you may have been down this path on one side, the other, both or even worse, at referee.
While some things may seem as inevitable as the sunrise, not all of them need be. Case in point, the dance of the pointing finger. What if instead of baseless accusations, you were able to quickly and painlessly answer the question of where the fault lies with data rather than guessing and intuition?
For example, we have seen many organizations tell us that due to recent events use patterns have changed. Some paths, like on-prem networks serving company offices, are seeing significant decreases in use, while others like VPNs and anything supporting teleworkers has been hit with massive increases.
We all know that theoretical performance and real world performance can be very different animals. What if you had a way to proactively test parts of your network with simulated traffic from one of over 400 applications? What if you could use synthetic monitoring to find problems before users reported them?
Another area this white paper covers is how a network visibility solution can help not just with finding performance problems, but also with addressing them. One example is filtering. In many cases networks will have traffic that you want to feed to analytics and security tools, but that traffic might be redundant or have some things in it that you don’t need to run security checks on. Network packet brokers let you apply advanced filters, reducing the load on your tools. In the case of Keysight packet brokers, the filters can be as fine grained as application level – with one example being the ability to filter Netflix traffic based on video genre – pretty cool.
You can also do some interesting things with load balancing and providing traffic to tools with different interface speeds (things like supporting 10G, 40G, and 100G tools in the same network while sending appropriate amounts of traffic to each).
Anyway, these things and more are covered in Troubleshooting Network QoS and Performance Issues. In the meantime, back in the Serengeti, after a period of circling and stalking, AppOps and NetOps have seemingly reached an uneasy truce. Apparently the database performance issues users were reporting were due to an issue with the network. Fortunately the organization had an advanced network visibility solution in place and the team was able to isolate the problem to a sick firewall which while it remained up and was passing traffic, it was doing so at an impaired rate. Thanks to bypass switches and other failover and high availability features they built into the network, the team was able to swap out the ailing box without downtime and bring its replacement up and get it running without needing to wait for a maintenance window.
Stay safe and thanks for reading.