Your network is running slow. What are the best network engineering tools to improve performance?

Too many false positives for mine when examining various Network Analysis Tools. It becomes a constant battle in investigating noise. I know you can suppress alerts for false positives, but then another one pops up. You can spend your entire time trying to tweak these things. Not a fan of an omnipresent Network Analysis Tool for large networks. Splunk is OK if it fed with the right data e.g. syslog, SNMP Traps, any csv that is relevant really. It is OK...wouldn't go further than that though.

In certain analyses, we can detect simple things that are causing major impacts on network traffic. A good example is a failure and/or negligence in the routing decision, causing a data flow to go back and forth through the same interface more than twice. Remembering that an analysis like this is work that demands attention and care, mainly because it brings downtime in some scenarios.In certain analyses, we can detect simple things that are causing major impacts on network traffic. A good example is a failure and/or negligence in the routing decision, causing a data flow to go back and forth through the same interface more than twice.

For optimizing network performance, consider using tools like SolarWinds Network Performance Monitor for comprehensive monitoring and analysis, Riverbed SteelCentral for end-to-end visibility and optimization, and Wireshark for in-depth packet analysis. Additionally, tools like Cisco's NetFlow or sFlow can provide valuable insights into traffic patterns and bandwidth utilization, while automation tools like Ansible or Puppet can streamline network configuration and management tasks. Always tailor your tool selection to the specific needs and challenges of your network environment for the best results.

An excellent traffic flow tool can identify content most used by users in service providers, for example, which helps with financial and operational decisions when contracting an IP transit link. Spulunk and SolarWinds are examples of tools for this task.

QoS settings are only applicable in your own network. The Type Of Service (TOS) bits in the header are not honored if the traffic traverses the internet - for good reason. If it were honored and given preference, then everyone would shape their packets to be ToS 5 (real time) and nothing would work. As for bandwidth monitoring, TCP Windowing will throttle traffic rates to account for available bandwidth. Here we have to divide traffic into "interactive" or "batch". Batch files will be little affected by congestion whereas interactive traffic over a congested link will be affected by TCP retransmissions. The user notices the latter. We use Techniche's Statseeker and I can recommend that for large scale network bandwidth monitoring.

In nearly 30 years in the Telecommunications industry, I am yet to find a tool that accurately creates a diagram of a large-scale network despite the claims of Sales staff who try and peddle these programs. Do not waste your time and money with these tools if you are managing a medium to large scale network. I manage over 2,000 routers and switches - how on earth are you going to fit all those devices into a diagram, or a set of diagrams. Algebraic/Tabular data, as opposed to graphical data (created by Network Mapping Tools), is the correct format to look at your large-scale network.

Finding a tool for this purpose is not an easy task. Usually the combination of two or more solutions solves this problem. I can give an example of Zabbix. A excellent map creation tool, with its poor intuitiveness for the user. I like working alongside it, be it a desktop background or Mikrotik's The Dude itself to create color-based links for each type of circuit capacity, facilitating debug, tshoot and future topology upgrades.

Latency is one important measurement. Smokeping (Tobias Oetiker) is an amazing tool that provides quality graphical data and can send alerts to those who need it. But you need to understand jitter as well. For real time applications to work over a distance, the receiving device must receive the packets in around the same time and frequency that the sender is sending. That way a real time visual or audio can be re-created at the far end (Codec discussion another day). Jitter is the variance in packet arrival. Latency is the time it takes for packets to arrive from the sender. High jitter means that the receiving end cannot re-create real time traffic because the packets are arriving infrequently.

Nowadays, with different vendors and their deployment methods, different names of solutions for the same purpose, one has "this" but not "that", it is important first of all that a given operation has a standard of deployment and operation so that the entry of a feature, solution and technology does not impact current production, even after a POC. Given this, choose the tool, solution or a set of both, which the operator and those responsible will implement and keep (the most difficult) operational.

ping and traceroutes are important troubleshooting utilities. Know all the flags when executing these commands. If you are operating in a Cisco environment, know your extended and vrf ping commands. iPerf is a Linux tool (open source) that is great for locating bottlenecks. Was recommended to us by Cisco. Examine your logs. People forget to do this and often the information about the cause is right under their noses. Know a little bit about the Linux CLI so you can quickly parse large syslog files. The Linux CLI utilities "grep", "cut" and "sed" are very handy. I've parsed things out of large files using cut, sort, uniq and sed all on the one line and seen people gawk in amazement at what you can do from the CLI.

At this point I believe that the MTR tool is more useful for those who want a diagnosis based on hops, latency, route, among others. Clearly, if all ASN operators implemented Looking Glass, many people's lives and time would be grateful.