David K, one of my YouTube subscribers, asked a great question, “… How do i configure packet slicing? …”. What a great question since I assume the reader knows how to do this.
In this video I cover how to figure out the packet slicing value for a HTTP GET command and the destination MAC address. From these two examples, the reader should be able to calculate any other packet slice value.
Packet slicing is one of those features that can make a huge difference when capturing network traffic, especially when you're dealing with busy links or collecting packet captures for extended troubleshooting. Instead of saving every byte of every packet, packet slicing allows your capture tool to keep only the first portion of each frame. This reduces storage requirements, lowers the workload on some capture devices, and can make large packet captures much easier to manage. The important part is knowing exactly how many bytes you actually need before the payload gets removed. A common mistake is assuming there is a universal slice value that works for every network. Unfortunately, there isn't. The number of bytes required depends on the protocols involved and the size of the headers in the packets you're capturing. Ethernet, VLAN tags, IPv4 or IPv6 headers, TCP options, and application protocols can all change where the useful information begins. That's why the safest approach is to examine an actual packet in Wireshark and calculate the offset rather than copying someone else's slice value. Wireshark makes this surprisingly easy because every packet is displayed as a collection of protocol layers. You can expand the Ethernet header, followed by IP, TCP or UDP, and finally the application layer to see exactly where important information begins. For example, if you're interested in capturing an HTTP GET request, simply locate the beginning of the HTTP payload in the packet bytes pane and note the byte offset where the GET command starts. That offset becomes the minimum slice length required to preserve that information during future captures. The same technique works for non-application data as well. Suppose you're troubleshooting switches and only need the destination MAC address from every frame. Since the destination MAC appears at the very beginning of an Ethernet frame, only a small number of bytes are required. On the other hand, if you're analyzing DNS, DHCP, HTTP, or another higher-layer protocol, you'll need enough of the Ethernet, IP, and transport headers to reach the fields you're interested in. The goal isn't to capture everything—it's to capture enough bytes to answer the troubleshooting question without wasting storage on unnecessary payload. One of the biggest benefits of packet slicing is that it encourages more efficient packet capture planning. Before starting a capture, ask yourself what information you're actually trying to collect. If encrypted application payloads won't be useful, or if privacy and legal requirements mean payload data should be minimized, packet slicing can be an excellent solution. Just remember that header sizes can vary, particularly when VLAN tags, IPv6 extension headers, or TCP options are present. Always validate your slice length against real traffic in Wireshark first, and you'll end up with smaller, cleaner captures that still contain the information needed for accurate network troubleshooting.
