Blog Post

The Network Performance Monitors You’ve Probably Overlooked

Published
February 8, 2018
#
 mins read
By 

in this blog post

When people think of synthetic monitoring outside the firewall they often think of website monitoring or HTTP monitoring. While HTTP is one of the most widely used protocols, there are many other protocols that require synthetic testing from outside the firewall or from the end users’ perspective. It is just as important, if not more important, to include network performance monitoring from outside the firewall in your monitoring strategy.

Applications are now accessed via wireless and broadband networks, from traditional datacenters and from the cloud, downloading content from multiple providers. This results in an end user traveling multiple networks with multiple protocols to retrieve all relevant information.

All protocols relevant to the delivery of applications need to be reliable, available, and responding within appropriate thresholds. To clarify your needs, answer the following questions regarding your application and services:

  • Are DNS queries resolving?
  • Can I SSH into a server and make configuration changes?
  • Is mail being received from SMTP or IMAP servers?
  • Are users able to upload and download support files to an FTP server?
  • Is the NTP server reporting the correct time and keeping all servers synchronized?
  • Are packet loss and latency within expected thresholds?
  • Do the APIs return the correct information?

In our recent blog post, Is It Time to Rethink Your Network Monitoring Strategy, we discussed the traditional tools used for network performance monitoring including:

  • Device polling. Devices are queried via SNMP to collect data on interface status, traffic statistics, load, CPU, and memory.
  • Active probing. Network properties are measured from an application perspective by sending traffic onto the network to gather information. Requests can be as simple as a ping, or more complex application-level queries such as a request for a web page or the initiation of a VoIP stream.
  • Internet Protocol Flow Information Export (IPFIX). An IETF standard based on Cisco’s NetFlow to export IP flow information from routers and network devices. Information is captured on a device and sent to a centralized analyzer or network management system.
  • Packet captures. Traffic transmitted on the network is intercepted, logged, decoded and analyzed according to RFCs.
  • Data logging or log analysis. A collection of data from logs or audit trails to correlate events or understand user behavior.

These techniques don’t always provide the answers to the questions outlined above. Being able to see the network from the end user’s perspective can provide insight not achievable via the above methods.

Below are some of the unsung network performance monitors from Catchpoint you should be using to ensure the health of your network.

TCP/UDP

Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are two of the most widely used transport protocols on the Internet. TCP is a connection-oriented protocol and requires a three-way handshake before any packets can be delivered. UDP, on the other hand, is a connectionless protocol. UDP is typically used by applications and services needing fast transmission and can handle a little less precision. DNS, video streaming, and gaming often use UDP.

Traceroute tests for both TCP and UDP can be configured within Catchpoint to test the availability of a given host and port. When a failure occurs, additional troubleshooting tools are available to verify a failure or collect debugging information.

DNS

Without DNS, users would never be able to find a website. This critical component of application delivery is often the cause of application outages. With multiple servers and resolvers involved in the DNS resolution process, it is easy for something to go wrong.

Catchpoint offers three different types of DNS tests to verify performance and troubleshoot both IPv4 and IPv6 addresses.

DNS experience tests simulate how users will resolve DNS from their devices. Tests are executed against randomly selected servers from each level of the DNS route. The availability, response time, and validity of the response is tested to protect organizations from DNS cache poisoning. Multiple requests are issued in succession to reveal whether a problem is related to all name servers of isolated to a single name server.

DNS direct tests are executed from an individual DNS resolver either by IP address or domain name to get detailed information on a specific server. They can also be used to test third party resolvers such as Google’s public DNS resolver to ensure settings are consistent across resolvers.

DNS traversal tests are available for instant tests and can be used to debug and isolate issues seen in DNS experience or HTTP tests.

SSH

SSH is everywhere. It is the primary protocol used to run commands remotely. As more and more tasks are being automated, it becomes more important to monitor SSH to ensure it is available and reliable. If SSH isn’t working properly automated tasks will fail and that can lead to a domino effect of negative consequences.

The SSH monitor from Catchpoint, when included in your network performance monitoring strategy, can connect to a server and runs shell commands to verify the server is functioning properly.

MQTT

The Internet of Things (IoT) has revolutionized the way we interact with everyday devices from tracking our exercise to controlling the temperature in our home. Message queuing telemetry transport protocol (MQTT) is the protocol that helps make this possible. The performance and availability of publish and subscribe communications over MQTT can be monitored with Catchpoint to ensure efficiency with the communication between devices.

SMTP and IMAP

Even though email is being replaced by communication and collaboration platforms such as Slack or Teams in some organizations many companies continue to rely on email for internal and external communication. If email is still a primary or secondary form of communication in your organization are you monitoring IMAP and SMTP? Being able to authenticate to a mail server and ensure that messages can be sent and received ensures communication doesn’t stop within your organization.

FTP

While newer methods of transferring files have emerged, FTP is still heavily used in many organizations to manage software downloads or transferring large files. Financial services firms especially continue to rely on FTP to process transactions. Don’t forget this “old” protocol when developing your network performance monitoring plan. Confirm that FTP servers can accept connections, properly authenticate users, and upload or download files.

For more information check out our recent ebook Ultimate Guide to Network Protocols.

When people think of synthetic monitoring outside the firewall they often think of website monitoring or HTTP monitoring. While HTTP is one of the most widely used protocols, there are many other protocols that require synthetic testing from outside the firewall or from the end users’ perspective. It is just as important, if not more important, to include network performance monitoring from outside the firewall in your monitoring strategy.

Applications are now accessed via wireless and broadband networks, from traditional datacenters and from the cloud, downloading content from multiple providers. This results in an end user traveling multiple networks with multiple protocols to retrieve all relevant information.

All protocols relevant to the delivery of applications need to be reliable, available, and responding within appropriate thresholds. To clarify your needs, answer the following questions regarding your application and services:

  • Are DNS queries resolving?
  • Can I SSH into a server and make configuration changes?
  • Is mail being received from SMTP or IMAP servers?
  • Are users able to upload and download support files to an FTP server?
  • Is the NTP server reporting the correct time and keeping all servers synchronized?
  • Are packet loss and latency within expected thresholds?
  • Do the APIs return the correct information?

In our recent blog post, Is It Time to Rethink Your Network Monitoring Strategy, we discussed the traditional tools used for network performance monitoring including:

  • Device polling. Devices are queried via SNMP to collect data on interface status, traffic statistics, load, CPU, and memory.
  • Active probing. Network properties are measured from an application perspective by sending traffic onto the network to gather information. Requests can be as simple as a ping, or more complex application-level queries such as a request for a web page or the initiation of a VoIP stream.
  • Internet Protocol Flow Information Export (IPFIX). An IETF standard based on Cisco’s NetFlow to export IP flow information from routers and network devices. Information is captured on a device and sent to a centralized analyzer or network management system.
  • Packet captures. Traffic transmitted on the network is intercepted, logged, decoded and analyzed according to RFCs.
  • Data logging or log analysis. A collection of data from logs or audit trails to correlate events or understand user behavior.

These techniques don’t always provide the answers to the questions outlined above. Being able to see the network from the end user’s perspective can provide insight not achievable via the above methods.

Below are some of the unsung network performance monitors from Catchpoint you should be using to ensure the health of your network.

TCP/UDP

Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are two of the most widely used transport protocols on the Internet. TCP is a connection-oriented protocol and requires a three-way handshake before any packets can be delivered. UDP, on the other hand, is a connectionless protocol. UDP is typically used by applications and services needing fast transmission and can handle a little less precision. DNS, video streaming, and gaming often use UDP.

Traceroute tests for both TCP and UDP can be configured within Catchpoint to test the availability of a given host and port. When a failure occurs, additional troubleshooting tools are available to verify a failure or collect debugging information.

DNS

Without DNS, users would never be able to find a website. This critical component of application delivery is often the cause of application outages. With multiple servers and resolvers involved in the DNS resolution process, it is easy for something to go wrong.

Catchpoint offers three different types of DNS tests to verify performance and troubleshoot both IPv4 and IPv6 addresses.

DNS experience tests simulate how users will resolve DNS from their devices. Tests are executed against randomly selected servers from each level of the DNS route. The availability, response time, and validity of the response is tested to protect organizations from DNS cache poisoning. Multiple requests are issued in succession to reveal whether a problem is related to all name servers of isolated to a single name server.

DNS direct tests are executed from an individual DNS resolver either by IP address or domain name to get detailed information on a specific server. They can also be used to test third party resolvers such as Google’s public DNS resolver to ensure settings are consistent across resolvers.

DNS traversal tests are available for instant tests and can be used to debug and isolate issues seen in DNS experience or HTTP tests.

SSH

SSH is everywhere. It is the primary protocol used to run commands remotely. As more and more tasks are being automated, it becomes more important to monitor SSH to ensure it is available and reliable. If SSH isn’t working properly automated tasks will fail and that can lead to a domino effect of negative consequences.

The SSH monitor from Catchpoint, when included in your network performance monitoring strategy, can connect to a server and runs shell commands to verify the server is functioning properly.

MQTT

The Internet of Things (IoT) has revolutionized the way we interact with everyday devices from tracking our exercise to controlling the temperature in our home. Message queuing telemetry transport protocol (MQTT) is the protocol that helps make this possible. The performance and availability of publish and subscribe communications over MQTT can be monitored with Catchpoint to ensure efficiency with the communication between devices.

SMTP and IMAP

Even though email is being replaced by communication and collaboration platforms such as Slack or Teams in some organizations many companies continue to rely on email for internal and external communication. If email is still a primary or secondary form of communication in your organization are you monitoring IMAP and SMTP? Being able to authenticate to a mail server and ensure that messages can be sent and received ensures communication doesn’t stop within your organization.

FTP

While newer methods of transferring files have emerged, FTP is still heavily used in many organizations to manage software downloads or transferring large files. Financial services firms especially continue to rely on FTP to process transactions. Don’t forget this “old” protocol when developing your network performance monitoring plan. Confirm that FTP servers can accept connections, properly authenticate users, and upload or download files.

For more information check out our recent ebook Ultimate Guide to Network Protocols.

This is some text inside of a div block.

You might also like

Blog post

When SSL Issues aren’t just about SSL: A deep dive into the TIBCO Mashery outage

Blog post

Preparing for the unexpected: Lessons from the AJIO and Jio Outage

Blog post

Demystifying API Monitoring and Testing with IPM