Availability issues. Slow response times. Performance bottlenecks. Also web applications have problems that affect the satisfaction of your employees and customers. Identify and troubleshoot them before they impact your business with Flowmon APM, an agent-less solution to proactively drive user experience and application value.

 Application Performance Management for IT Operations

For more information about this application, click here .

Network management and monitoring is a large topic. It includes device monitoring and management, device cluster monitoring and management,network monitoring and management, application monitoring and management, problem resolution, and elements of network security as well. In this blog, I wanted to focus on device monitoring.

Devices are often referred to as network elements (NEs). They are millions, probably billions, of devices worldwide when you count printers, switches, routers, taps, etc. At this point, I’m not necessarily talking about the Internet of Things (IoT), where there are billions of end user devices that connect “into” the network. The devices I am referring to “are” the network. Each of these devices need to be managed and monitored once they are installed into the network. Simple Network Management Protocol (SNMP) is often the protocol of choice for this endeavor.

​

What is anSNMP? 

SNMP is a device management protocol first developed by the Internet Engineering Task Force (IETF) in 1988. It uses Internet Protocol (IP) for communication. There are three components to an SNMP-based architecture: the devices being managed, agents, and the controller (called a network management system (NMS)).

SNMP is used to manage all sorts of devices. This includes: routers, switches, hubs, and lots of other IP-based network devices. The NMS communicates to these devices to get information from the device, to set values in the device’s variable list, and to receive asynchronous messages from the agent (often called a “Trap”).

​

Typical Use Cases 

 Here are some specific situations in which SNMP is particularly useful:

Component monitoring – Gathering basic data from devices like operational state, temperature, specific counts for pertinent data, data reports, etc.

Component management – Pushing new configuration changes to the device, initiating resets, and changing data reporting parameters.

​

Considerations

While device management and monitoring is important, here are some other things to keep in mind when monitoring your network:

Understand your NMS – Can it be integrated with the rest of your network management activities or will this be a stand-alone island? Using SNMP to control individual devices is important but many vendors have an element management system (EMS) that configures their individual devices. It may or may not us SNMP and there is a good chance it may not expose the SNMP data to your other management systems. This means that you need to be cognizant about how element management systems you will have in your network, what you can and cannot do with each one, and often you need to use each one. The fewer number of systems you interface with will lower costs and lower device management fatigue.

Understand device and NMS interoperability – Besides SNMP, there are other important protocols like REST. Do your devices and NMS system(s) support the REST protocol so that you can automate function and control of devices within your network? This will be very important to controlling management costs.

Thank you to Keith Bromely of IXIA, a Keysight  Business, for the article.

Encrypted traffic is on the rise. It’s no longer possible to inspect the content of the communication. What does this mean for network traffic monitoring?

Encrypted traffic is on the rise. In 2016, NSS Labs found out that 97% of surveyed enterprises saw an increase in encrypted web traffic. Both Let’s Encrypt and Google  currently report between 70% and 90% of traffic is HTTPS (HTTP encrypted with SSL/TLS). Google has been pressing for HTTPS for a while now. Back in 2014, they started taking into account whether the website uses HTTPS for page ranking, and in 2017 Google Chrome browser started showing “Not Secure” warning in the address bar when visiting websites without HTTPS. In August 2018, Scott Helme, a Security Researcher, analyzed 1 million most popular websites – over 51% are already using HTTPS. Gartner predicts 80% of traffic will be encrypted in 2019.

What does this all mean for network traffic monitoring?

Using encryption it is no longer possible to inspect the content of the communication. Let’s take a look at the following screenshots from a popular packet capture tool – Wireshark. Let’s visit the website – example.com. At first, without encryption (plain HTTP) – http://example.com. In Wireshark we can dive deep and inspect the HTML code of the website content being transmitted from the server to the client. Anybody can intercept our communication and take a look themselves:

The contents are now no longer readable. This is sad news for anyone trying to spy on us. They can no longer get our credit card information or other sensitive data. This is why Let’s Encrypt and other organizations push for HTTPS. It makes our online lives more secure.

Now, we can all agree that encryption is great, pat ourselves on the back for spreading the HTTPS gospel and go home, right?

Well, not so fast. What if you need to know what is going on in your network? What are you going to do when there is an issue with the critical business application? Does your network administrator still rely on legacy packet capture solution for troubleshooting and monitoring? What can you do when you can no longer inspect the contents of communication?

Briefly, consider an example of detecting BitTorrent traffic in a network. In the past it was only a matter of checking the TCP port number (the range for a BitTorrent is 6881-6889). However, nowadays client applications tend to randomize port numbers. It was too easy to block the said ports on the firewall. It’s fairly straightforward to perform deep packet inspection (DPI) when packets are unencrypted. Examples of BitTorrent signatures are “GET /announce?info_hash”, “GET / request” and “GET /torrents/”. The DPI engine looks for these strings within the payload, and once found BitTorrent traffic is detected. Unfortunately, most of the client applications encrypt BitTorrent communication by default. Users can disable encryption, but they still accept encrypted traffic from their peers (other BitTorrent clients) and thus reducing the detection success rates.

Luckily, we can leverage flow data to detect BitTorrent traffic. By design, a BitTorrent client makes a lot of connections with peers in a short time interval, peers are located all around the globe and many connections fail because peers are offline. In short, we can detect encrypted BitTorrent communication with flow data as it is based on client behavior rather than the contents of the communication. Learn more about sources of flow data in our previous post Where Do The Flows Come From?.

In summary, with encryption on the rise it no longer makes sense to monitor your network with packet capture solutions. With flows it doesn’t matter whether the content of communication is encrypted or not. We leverage information and metrics from lower network layers, which are not encrypted. Thanks to this approach, our network and security monitoring solution works even on encrypted traffic.

Thank you to Roman Luks from Flowmon for the article.