Inline and Out-of-Band Monitoring — What Do You Mean

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?

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:

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.

limit
3