<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">It sounds like a fantastic addition. <div><br></div><div>Dave</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div><span style="font-size: 13pt; background-color: rgba(255, 255, 255, 0);">Regards,</span></div><div><span style="font-size: 13pt; background-color: rgba(255, 255, 255, 0);">David Edelman </span></div><div><span style="font-size: 13pt; background-color: rgba(255, 255, 255, 0);">who is responsible for the concept of this message. Unfortunately, autocorrect is responsible for the content</span></div></div><div dir="ltr"><br><blockquote type="cite">On Oct 7, 2024, at 11:44, Carter Bullard <carter@qosient.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Gentle people,</span><br><span>I’ve recently been working with a site that is running 100G argus sensors, and we ran into an issue trying to debug some non-conventional tunneling. They were seeing foreign IP addresses in their flow data, which tripped their IDS, once every 4-5 days, and they couldn’t figure out where the data was coming from. </span><br><span></span><br><span>Argus was generating flows with unexpected encapsulations and foreign L3 addresses … Seems natural that people want to question the sensor first, so we needed to validate that the flows were real, the encapsulation parsing was correct, and that the data was captured and reported correctly … Debugging this type of sensor can be difficult when there are issues, as you typically need to collect packets that can reproduce the condition / problem. Unfortunately, traditional packet capture at 100G is tricky … In this particular situation, we were getting a packet that was in an unknown tunnel once every 4 or 5 days, which means we needed to figure out how to capture 1 out of 10^12 packets, without killing the sensor or having to buy a bunch of disks.</span><br><span></span><br><span>Generally, when we can, we leverage argus itself to do packet capture for debugging. In argus-5.0, there is support for total packet capture (dump packet before processing) and selective packet capture on error (dump packet if there is an error in parsing) which can be configured using the argus.conf file. These two schemes help a lot in developing and debugging argus when there are issues. These schemes proved impractical for this problem, as using full packet capture to get 1 out of 10^12 is not really helpful, and there weren’t any errors when parsing out the packets.</span><br><span></span><br><span>As a result, we engineered a “capture on protocol” feature, which solved the problem in this case. The crazy flow was a GRE tunnel inside a VxLan encapsulation, but with VLANs and unknown potential UDP encapsulations, in a population of VxLAN / GRE / IPnIP , we couldn’t formulate a Wireshark or tcpdump filter that could reliably match the packet condition … So we put a small bit of logic in Argus’s header parsing routine to check if a protocol mix existed, and enabled any of the argus threads to generate a libpcap dump file for those packets. This worked right out of the gate, and we grabbed 10 packets over a period of a month … A month of packets at 100G, full line rate, is about 5.18x10^12 packets, so mission accomplished.</span><br><span></span><br><span>I believe that this is a great new feature but wanted to poll the group to see if they have a need or see benefit to adding this support to argus-5.0.</span><br><span></span><br><span>Hope all is most excellent,</span><br><span></span><br><span>Carter</span><br><span></span><br></div></blockquote></div></body></html>