[ARGUS] How many layer from tunnels can argus detect

[Carter Bullard]

Hey Ming,
Sorry, but I don’t know what a ’samples operating sequence’ is …
What are you looking for ???

Carter


> On Jun 25, 2024, at 11:20 AM, Ming Fu <Ming.Fu at esentire.com> wrote:
> 
> Hi Carter,
>  
> Thanks for the explanation. Is there a document or samples operating sequence I can use as reference?
>  
> Regards,
> Ming
>  
> From: Carter Bullard <carter at qosient.com>
> Sent: Tuesday, June 25, 2024 10:42 AM
> To: Ming Fu <Ming.Fu at esentire.com>
> Cc: Argus <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] How many layer from tunnels can argus detect
>  
> Hey Ming,
> There is no limit to the number of headers argus will parse through to get to the end-to-end transport headers.  Usually it is controlled by the packet snaplen … if you turn on the control plane capture support in your /etc/argus.conf file, then the snaplen becomes max packet length, and argus will have the complete packet contents to parse.
>  
> ARGUS_TUNNEL_DISCOVERY is really about TEREDO like tunnel discovery, and is probably broken, so that would not work for you …
>  
> While argus will parse the headers, and it will report on all the tunnels with the ‘flgs’, ’senc’ and ‘denc’ fields, argus is only reporting a controlled number of headers ... 1 L2 header, the outermost header, upto 8 MPLS labels, 2 VLAN headers, 1 VxLan header, and currently, only 1 IP header, and 1 transport header.  This is because we have separate DSRs for these services, and argus supports only 1 DSR type per record, at least right now.
>  
> I have a new branch in the argus repo, carter/gre, that adds 1 GRE header, which provides for 2 additional IP headers to be tracked.  This branch should be the basis for adding additional tunnel support that we might need.  If you are willing to share some of your packets, we can use your case to further develop the tunnel support, which is a priority for argus 5.0.
>  
> If we do parse the GENEVE tunnel headers (not 100% sure that we do), then argus will continue into the tunnel to find the inner IP header.
> If we don’t parse the tunnel, then the user data buffers will have the packet contents, which can be parsed by radump.1 … if radump doesn’t do the trick, we can fix that if you are willing to share some of your flow records.
>  
> Carter
> 
> 
> On Jun 24, 2024, at 3:39 PM, Ming Fu via Argus-info <argus-info at lists.andrew.cmu.edu <mailto:argus-info at lists.andrew.cmu.edu>> wrote:
>  
> Hi Carter,
>  
> I have a double tunneled traffic to argus 5. The outer tunnel is VXLAN, the inner tunnel is GENEVE, the real traffic inside the inner tunnel is Eithernet/IP. I have the ARGUS_TUNNEL_DISCOVERY="yes” set. I can use ra to search for the outer tunnel IP and inner tunnel IP, but I can’t search the actual packet inside of the inner tunnel. Is the tunnel discovery limited to one tunnel, or I did not configure properly?
>  
> Regards,
> Ming

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20240625/a3539319/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1385 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20240625/a3539319/attachment.bin>