… or the 3 major problems with packet capture in modern networks
Packet capture and analysis is troubleshooting technique that has been around for many years now, and for sheer power and completeness there is arguably no better diagnostic technique to identify network and security issues.
Networks have become larger and the modern topologies have made the ability to perform packet capture difficult. New network technologies such as SD-WAN mean that network traffic no longer necessarily traverses a single egress point but often sees remote sites with their own Internet connection. Whilst a great improvement for user performance, these new network topologies make troubleshooting more difficult by restricting visibility of what is happening at each site.
Packet capture is particularly difficult in these large distributed environments and as the need for diagnostic techniques like packet capture remain, the barriers to implementation are high. Let’s consider the 3 primary obstacles to packet capture in distributed network environments:
By it’s very nature, packet capture is complex. The ability to interpret packet traces and pinpoint security or performance issues requires a highly skilled (and expensive) network engineer. It is probably not a great use of a network engineers time to be sent to a remote site specifically to collect a packet capture.
Connecting a packet analyser to the network is difficult. Two common techniques involve configuration of a SPAN/mirror port on the switch or installation of a network tap. Configuring a SPAN port needs admin access to the switch, which is typically not easy, whilst installing a network tap requires a network outage to place the tap inline. Both these options are problematic in a production network.
The nature or network performance or security issues is ephemeral. By the time you dispatch an engineer to site to initiate a capture, chances are the issue is gone. What we need is the ability to turn on captures at will without the delay of physically attending a remote site
So here we have somewhat of a paradox, the benefits of a packet capture are high, but are the benefits high enough to outweigh the expense and effort of implementation? Put simply does the cost of the packet capture solution cost more than the problem we are trying to fix?
At the core of the issue is that packet capture is typically a ‘standalone’ diagnostic tool. That is, we ship an engineer to site with a standalone laptop or analyser to plug in and grab the capture. Engineers and laptops are expensive, not the sort of thing you want to have on call at every site in the event that you just might have an issue requiring a packet capture.
We need to change our mindset from standalone to distributed – that is a distributed packet capture solution. The distributed solution needs to be cost effective enough to be able to be installed in every remote site to allow immediate remote access to packet capture from a central location. It must also be centrally controlled so that engineers can initiate the capture from a simple web interface from anywhere.
This is exactly what the Byte25 solution delivers. A range of appliances suitable and priced for installation in very small remote sites right through to large multi GigE units for central data centre installation. The Byte25 solution allows network engineers to initiate remote packet capture anywhere from anywhere removing geographical constraints. The captures can be viewed immediately via the Bye25web user interface or downloaded to a third party analyser like Wireshark for deeper analysis.
The Byte25 distributed packet capture solution removes the constraints traditionally associated with packet capture at remote sites and enables one of the most powerful diagnostic techniques in the network engineers arsenal.