When introducing new monitoring equipment to your network, there are two ways it can be deployed: out-of- band or inline. The latter, inline deployment, places the equipment to interact, manage and/or analyze actual network traffic. On the other hand, out-of-band equipment receives a mirrored copy of the network traffic; this is away from directly affecting the production network.
This eliminates the risk of introducing additional latency and potential mismanagement that newly tested inline devices might do. Introducing inline tools is a matter of trial and error. This means testing the waters with increased certainty for each consecutive iteration. These steps can lead to a tedious and lengthy process for validation.
Making the inline validation process faster and more effective requires a larger set of data that the inline device is exposed to and have the ability to retrieve data it wants to reexamine. Think of the inline device as an Italian language learner listening to 2 conversations. If the device failed to catch a phrase, then it should have a method to rewind and play it back. Eventually, its capabilities will improve and 2 conversations might not be enough for the inline device to learn. Increasing it to 10 conversions is needed to speed up its training to become an interpreter. Essentially the inline device in trial for validation needs a high speed, out-of-band network traffic recorder and replayer to increase the inline devices capability in listening and interpreting these network “conversations”.
Out-of-band devices, like the Quantea QP Series, can provide an inline monitoring device effectiveness since it can utilize months worth of network traffic data instead of having the inline device itself collect months worth of data - it does not have the storage to do that.
Performance is key to both accuracy and precision. Both inline and passive devices have to be comfortable keeping up at line rate speeds. In cases where the inline device can only handle 75% line rate speeds, it can rely on the out-of-band device to fetch the missing 25% since it can catch up to 100% line rate. If the inline device is used to itemized HTTP and DNS response codes, missing 25% of the data will portray a different picture of the network compared to having 100% of the data. If an image causes a particular web page to crash, the organization would greatly benefit if their inline tool was able to retrieve an entire copy of that image before and after the incident. Luckily an out-of-band tool can retain such information.
Much like the human body, each network has its own set of quirks, behaviors and levels of complexity. Having a way to record some of the network’s history by using an out-of-band device will help network transition to a new inline device seamlessly. It is like passing a patient’s record to a new doctor.
A key component for both inline and out-of-band devices to work together is interoperability and common data types. The out-of-band tool will need to provide a method, whether it is through an API or some form of automated data access, for the inline tool to harness the network traffic data collected over time. In addition, the data exchanged between should be able to be easily read and parsed by the inline tool. This can be in a form of JSON, XML or packet logging binary like PCAP.
Whether it is routing, switching, mitigating, monitoring or shaping production traffic, inline tools are essentially the cogs that keeps the network functioning. Therefore, non- impacting out-of-band devices are there to augment the effectiveness of tools such as inline monitoring. To ensure this effectiveness, the out-of-band tool needs to record at a 100% line rate and provide a good amount of interoperability so that the inline tool can make use of the data inside.
[Want to learn more about how Quantea's QP Series works with Garland Technology TAPs and Packet Brokers to provide 100% packet capture for complete recall, retention, and storage of data? Check out our joint solution to learn more.]