Purpose and Typical Cases of Inline and Out-of-Band Monitoring

PublishTime： 2022-04-09 Article Source：Keysight

When it comes to network monitoring, there are two scenarios—out-of-band and inline (in band). This definition typically refers to the placement of the equipment from the monitoring tool's perspective. Basically, is the monitoring tool in the critical path of network data or not? If the tool is not in the main data path and just using copies of the packets, then it is called out-of-band. If it is actually processing the original data, it is said to be inline. It's that easy.

The next question, of course, is why does it matter?This artical Keysight will introduces the purpose and typical use cases of Inline and Out-of-Band Monitoring.

Purpose of Inline and Out-of-Band Monitoring

The type of monitoring scenario, out-of-band or inline, effects the placement of monitoring equipment, the type of equipment used, and the monitoring activities you can conduct as part of your visibility architecture. For instance, firewalls are typically located at the company's main network interface to the outside world. Because of this, they are placed inline. An intrusion detection system (IDS) is typically not placed inline. It is installed as part of an out-of-band scenario since, while it is used to sample data for intrusions, it is not intended to inspect every packet that traverses the network.

For inline tools, data access starts with a bypass switch. Think of this as a special tap for monitoring tools that you insert directly into the flow of the network data. If you had just inserted the tool, and it failed completely or you yanked the tool out, this would directly affect, i.e. stop the flow of data to the rest of the network. A bypass switch has fail-over capability that let's the network survive if the tool connected to it fails. If a network packet broker (NPB) is inserted between the bypass switch and the tool(s), then other functions like filtering and load balancing of network data are possible.

In an out-of-band monitoring scenario, a passive tap is inserted into the network for data access. This device doesn't need the fail-over capability because the monitoring equipment is not directly in the flow of network traffic, so it's simpler. In fact, it's essentially set and forget. You normally don't have to do any programming to taps. While the tap is in the direct path of traffic, all equipment that is receiving a copy of the traffic is completely out of the traffic path for network traffic. You can connect or disconnect whatever equipment you want to the tap monitoring port and it will NOT affect the rest of the network. In this scenario, a packet broker can also be inserted between the tap and tool to perform filtering, load balancing, deduplication, packet slicing, data masking, and lots of other functions.

Typical Use Cases

Here are some common use cases for inline and out-of-band monitoring scenarios:

Security (both scenarios) – Security monitoring solutions involve inline components like firewalls, intrusion prevention systems (IPS), honey pots, serial chaining of suspect data, and threat detection solutions. Out-of-band solution examples include forensic analysis with data loss prevention (DLP) tools, intrusion detection system (IDS) analysis, and forensic packet recording.

Cost controls (both scenarios) – Both scenarios offer cost saving capabilities like load balancing, data filtering/discrimination, floating filter creation, remote management, etc.

Survivability (both scenarios) – Both solutions provide improved survivability like the bypass switch and high availability for inline security tools as well as redundant components and fail-over NPB functionality for out-of-band solutions.

Performance monitoring (both scenarios, more common for out-of-band) – While some performance monitoring tools can be implemented as part of inline scenarios, most of these solutions will be out-of-band and focus on application and network monitoring. Proactive monitoring, the ability to test the network in real-time, is also an out-of-band solution.

Application intelligence (both, more common for out-of-band) – This feature is more common for out-of-band scenarios because of the analysis utility for application data. Application data can be used to help identify indicators of compromise, proactive troubleshooting, and to improve/demonstrate regulatory compliance.

Troubleshooting (out-of-band) – The out-of-band scenario allows for the collection of various data points that can be used to pinpoint problems. The existence of the data typically doesn't reveal the problem itself. That data needs to be sent to an analysis tool that requires a certain amount of time to analyze the data before a useful conclusion can be made. This time delay necessitates the need for an out-of-band scenario.

Compliance (out-of-band) – The out-of-band scenario allows for data masking and packet slicing to conceal packet data while it is stored. Data can also be filtered and sent to special purpose tools, like logging tools, for data storage to demonstrate compliance to various regulatory standards.

Virtual data center monitoring (out-of-band) – Out-of-band solutions are used for gaining access to monitoring data within a virtual data center. This includes a special purpose tap, called a virtual tap, to capture the requisite data and send that off to monitoring tools for data analysis.

Considerations

Here are some things to keep in mind to help determine whether you need an inline or out-of-band monitoring solution.

Monitoring Goals – What information do you wish to collect from the network and where are you planning to get it from? Determining an inline scenario is usually fairly simple. For instance, do you need to collect and process the actual data packets, or just copies of the data packets? Do you need to analyze and inspect every packet? These are inline scenarios. Out-of-band will essentially be everything else. This includes performance monitoring, forensic analysis of security risks, data analysis for compliance, troubleshooting network issues, etc.

Performance – Performance of the equipment will be paramount. You need taps, bypass switches and packet brokers that process data at full line rate under full load. Some of the visibility solution providers out there sell products that cannot operate at full line rate. So pretest your solution before you buy.

Scalability – Scalability is important for long-term cost controls. The solution needs to be able to support current bandwidth requirements and future requirements. You also need solutions that can be upgraded to higher data rates, like 100 GE, in the future.

Ease of Use – Packet broker filter creation needs to be as simple as making mouse clicks. A good packet broker will display filters within the main User Interface so that it's easy to see the connections and easy to understand what a particular filter is used for. You can use drag and drop functionality to start the flow of data to the filter. The packet broker should also support a remote interface so that you can make changes or place the floating filter into service remotely, i.e. no need to drive into the office. These features will be important to controlling operational costs.

More Information on Visibility Architectures

When all the components of a visibility architecture are combined, they eliminate the blind spots within your network and make troubleshooting much easier and faster.

+1 Like
Add to Favorites

Recommend

Selection Guide

More>

Technical Resources

More>

New Products & Solutions

More>

This document is provided by Sekorm Platform for VIP exclusive service. The copyright is owned by Sekorm. Without authorization, any medias, websites or individual are not allowed to reprint. When authorizing the reprint, the link of www.sekorm.com must be indicated.

Integrated Circuits