Tag Archives: netzwork analysis

Network Blog

Use monitoring resources more effectively thanks to intelligent Load Balancing

Posted on by Patrick Nixdorf
06
Aug

How do I distribute my network traffic for analysis
as effectively as possible using load balancing?

Problem

Often, analysis, monitoring and security systems have more than one port to accept and process incoming data from the corresponding network access points. Many of these systems have at least 2, 4 or even more ports ready to accept data.

Depending on the type and location of the various network access points, this offers the user the option of providing a dedicated physical port per tapped line. However, several factors are a prerequisite for this.

The speed and topology of the network lines to be analysed must be identical to the connections of the analysis system and it must be ruled out that further tap points are added in the future which are to be evaluated by the same analysis system.

Approaches

Apart from the problems with speeds and topologies, additional analysis systems can of course be installed at any time should the number of lines to be monitored increase.
However, this is often the most costly and time-consuming alternative. Besides the necessary procurement, it would mean for the user to deal with yet another system; an avoidable additional administrative effort.

To avoid such a situation, there are various options and, depending on the setup already in place, technical procedures can be used to distribute the incoming data from the measuring points more effectively to the physical ports already in place.
In many cases, it is primarily the ratio of data volume and number of measurement points to the number of available ports on the analysis system and not the basic amount of data volume that can lead to bottlenecks of a physical nature.

Both (semi-dynamic) load balancing and dynamic load balancing can help here, a feature that most network packet brokers include.
Here, a group/number of physical ports is combined on the Network Packet Broker and defined as a single logical output instance. Data streams that leave the Network Packet Broker via this port grouping are distributed to all ports that are part of this grouping, but the individual sessions remain intact.

Example

Dynamic Load Balancing Example Diagram

Let us assume the following example: 8 measuring points have been set distributed in the local network. A session between 2 end points runs via each tap point. The analysis system used is equipped with a total of 4 ports for data acquisition.
Even if one assumes that the measuring points are exclusively SPAN or mirror ports, there is still the problem that too many measuring points meet too few ports.

And this is where Network Packet Brokers with Load Balancing come into play. Load Balancing ensures that each session between 2 end points of each measuring point is sent as a whole to a single port of the connected analysis system.
For simplicity, assume that the 8 sessions of the 8 measuring points are distributed equally among the 4 ports of the analysis system, 2 sessions per port.

This is all completely dynamic and subsequently added sessions between endpoints are sent fully automatically to the ports of the analysis system that belong in the port grouping. It is not necessary to set up or change the configuration of the Network Packet Broker afterwards; the built-in automatisms allow the automated and reliable distribution of further data streams to the analysis system.

Of course, it is also possible to connect additional tap points to the Network Packet Broker and have their data included in the Load Balancing, as well as to expand the above-mentioned port grouping with additional output ports.
All these steps can be taken during operation, the additional data streams are distributed to the newly added ports of the analysis system in real time without interruptions.

Removing ports, even during operation, is no problem either! The Network Packet Broker is able to ensure that the packets/sessions are forwarded to the remaining ports of the analysis system without any loss of time or packets.

Dynamic Load Balancing Example Diagram without Network Packet Broker

Sessions & Tuples

But how can the Network Packet Broker ensure that entire sessions are always distributed on the individual ports of the load balancing group mentioned above?

For this purpose, a hash value is generated from each individual package. An integrated function ensures that in the case of bi-directional communication, the packets of both transport directions leave the Network Packet Broker again on the same port.

These hash values are determined using the so-called “5-tuple” mechanism, where each tuple represents a specific field in the header of each Ethernet frame. The available tuples on the Network Packet Broker (e.g. NEOXPacketLion), which are used for dynamic Load Balancing, are:

  • Input Port (Physical Connection)
  • Ethertype
  • Source MAC
  • Destination MAC
  • VLAN Label
  • MPLS Label
  • GTP Tunnel Endpoint Identifier
  • GTP Inner IP
  • IP Protocol
  • Source IP
  • Destination IP
  • Layer-4 Source PORT
  • Layer-4 Destination PORT

Depending on the structure and setup of the network, and depending on whether packets are transported using NAT, another very common distribution of tuples is:

  • IP Protocol
  • Source IP
  • Destination IP
  • Layer-4 Source PORT
  • Layer-4 Destination PORT

With “5-tuple” based Load Balancing, all the above-mentioned tuples are used to form a hash value which ensures that all packets, including the corresponding reverse direction, always leave the Network Packet Broker via the same port and thus, for example, the security system used always and fundamentally only receives complete sessions for evaluation.

Hash Values

In order to be able to generate the actual hash value on which the Load Balancing is based, the user has two different functions at his disposal, CRC32 and XOR.

By means of the CRC32 function, hash keys with a length of 32 bits can be generated and can be used both symmetrically and asymmetrically, while the XOR function creates a 16-bit long hash key, which, depending on the intended use, allows a higher-resolution distribution of the data, but can only output it symmetrically.

This symmetry means that even if the source IP and destination IP are swapped, as is known from regular Layer 3 conversations, the function still calculates the same hash key and thus the full Layer 3 conversations always leave the Network Packet Broker on the same physical port.

In the case of an asymmetric distribution, which is only supported by the CRC32 function, the Network Packet Broker PacketLion would calculate different hash values in the situation described above and thus also be output accordingly on different physical ports.

Dynamic Load Balancing - Screenshot - NEOXPacketLion Network Packet Broker
NEOXPacketLion Network Packet Broker – Screenshot

Dynamic Load Balancing

Another, additional function of Load Balancing is the possible dynamics with which this feature can be extended. In the case of dynamic Load Balancing, in addition to the hash value explained above, the percentage utilisation of each port that is part of the Load Balancing port group is also included in the calculation.

Of course, this procedure does not split any flows, and it also ensures that if a flow is issued based on the calculations on a specific port, this flow will always leave the Network Packet Broker via the same port in the future.

By means of a configurable timeout, the user can define when a flow loses its affiliation to an output port. In the event of a recurrence, this is then output to the participants of the load-balancing port group again in a regular manner and, both by detecting the load in the TX stream and by means of the hash value generation, it is determined which output port of the Network Packet Broker is currently most suitable for bringing the data to the connected analysis system.

Conclusion

It turns out that distributing the incoming data load by means of load balancing has been an effective way of utilising security, analysis and monitoring systems for many years. Over the years, this process has been further improved and culminates in the Dynamic Load Balancing that the PacketLion series has.

Constantly following up the configuration with regard to the distribution of the individual sessions to the connected systems is no longer necessary; this is now taken over by the intelligence of the Network Packet Broker and allows the user to use the full potential of his systems and avoid unnecessary expenditure.

Network Blog

Network Analysis – Packet Capturing

Posted on by Timur Özcan
15
Nov

Network packet analysis is a great method for diagnosing network problems. The data in the network or on the affected devices is recorded and examined with special analysis devices. This technique gives you a deep insight into the data packets and allows you to identify and correct errors very precisely.

Network analysis by means of “capturing” procedures is one of the most reliable analysis methods, as you receive unaltered information from the corresponding network connections to your network, server, client and application and can evaluate this data without loss and without interference. The data to be analysed is passed on completely and transparently from so-called Network TAPs to the analyser while maintaining data integrity.

Measuring point - Single or Multiple?

A SPAN port is often used as a measuring point, as it requires the least installation effort to access the relevant network data. The better measuring point is a network TAP.

I have described the advantages of Network (Ethernet) TAPs in my previous article and I assume that you are familiar with them. Certainly, it is possible to investigate the cause of the problem using a single measurement point on the network, but to determine the location of the problem, additional measurement points can be beneficial.

Depending on where you record the data, you get a different picture of the communication. Especially to determine “one-way-delay” or the location of packet loss, it is advisable to consider several measurement points. In addition, the use of several analysis points can significantly increase the quality of the measurement and problem analysis.

In this way, the recorded data can be conveniently compared with each other and latency, one-way delay, packet losses and other important parameters can be determined. Without a doubt, standard errors can also be limited or diagnosed with only one measuring point, but due to increasingly complex network infrastructures, there are significant advantages to multi-point analysis. You determine the capture points yourself and can thus more easily and accurately analyse the transport path of the packets and diagnose the identification of problem areas more quickly. Detecting anomalies and getting your network back on track becomes child’s play.

How does a multi-segment analysis work?

With this method, the network data is examined at several points in the network and compared with each other. However, especially with multi-segment analysis, time synchronisation is immensely important, as the result is strongly influenced and falsified by unclean methods. If I want to measure latency and delays precisely and accurately, then I need hardware with which I can capture the packets with nanosecond precision and provide them with an absolute time.

With special network capture cards that use FPGA to record the data, it is now possible to record data packets with 8ns accuracy. This method is also called time stamping and is supported by all professional analysis and measurement tools. But even without such FPGA cards, it is possible to perform multi-point analyses, namely by correlating the data at an analysis point, e.g. recording with Link Aggregation TAPs, or using OmniPeek Enterprise for analysis.

If the data is aggregated during the capture, it is important to mark the data traffic with a VLAN tag beforehand or to mark the measuring points directly during the capture in order to be able to recognise the origin of the data during the analysis. It is not uncommon to prefer the fast way of capturing data for time reasons and to collect the network data on the affected systems.

Tools such as TCPDump or Wireshark (PCAP) can be used, or the OmniPeek Remote Assistant can be consulted for help. If the trace data is now available from different systems (TAP, client, server, etc.), a correction of the absolute time is required, as otherwise an analysis is almost impossible. A special function in OmniPeek Enterprise allows you to manually correct the time differences between the different trace files by means of offset adjustments. OmniPeek will gladly take over this task for you and synchronise the time intervals so that you can concentrate on the essentials.

The more measurement points I want to roll out in the network, the more network interfaces are needed on the analysis computer. In our example we assume 4 measuring points. In this setup, the data is available in 4-fold form and must be written away accordingly. If you are only interested in the data of a single application, you can use filters to ignore the unwanted traffic before capturing and reduce the load on the analysis tool.

What is the advantage of multi-segment analysis?

Now it is about increasing the quality of the measurement and gaining valuable information from the network. Ideally, the data should be collected once at the client and once at the server and the other measuring points should be placed in the network, e.g. in the distribution and core area.

This would technically enable us to analyse the data packets and transactions from a certain client to the server in detail and to localise the location of possible errors. Proxies and many other security tools can cause latency or other critical errors due to performance problems, and these must be identified.

Why do retransmissions occur and what causes them? Where do packet losses occur and what is the cause; is it passive components or are network components to blame? If I have latency or jitter, I want to know where exactly it is occurring. These and many other questions can be answered by means of a multi-segment analysis.

Application of the multi-segment analysis

Nowadays, there are analysis tools that allow automated multi-segment analysis and eliminate the need to manually sift through packets. Fortunately, the OmniPeek product supports multi-segment analysis and shows you the paths of the packets graphically, simplifying the analysis of this data. The network data is displayed correlated on one screen together with the packet paths and the individual hops.

You can see the latencies caused and the packet losses that have occurred at a glance, without having to analyse them intensively. The valuable thing about this is that you can immediately see where the latencies and packet losses occur and, above all, in which direction. Furthermore, the routes and hops of network packets can be analysed and the runtimes or the quality or convergence time of HA connections can be measured.

Especially with real-time applications like VoIP, I would like to know where jitter or delay occurs. Especially with VoIP it is not difficult to detect quality problems, but to locate them precisely is usually a difficult challenge for a network administrator. Also the latency or other network errors between the WLAN and the LAN network can be measured and diagnosed with OmniPeek’s multi-segment analysis.

Proactive not reactive

Therefore, it is advantageous for network analyses and troubleshooting tasks to have fixed measuring points in the network, through which one can easily access the network packets if necessary. Furthermore, a proactive analysis is very helpful, as errors often occur and disappear again a short time later.

Especially in the case of sporadically occurring errors, it is very advisable to have fixed measuring points and to record the data for a certain period of time. This makes troubleshooting much easier and allows you to quickly identify errors that occurred in the past. Otherwise, you are in the dark and may not be able to isolate the error because it is no longer present or only occurs during certain events.

Thank you for your upload