Two TCP sessions in one flow record

Fri Jul 15 14:38:55 EDT 2016

Hey Jonatas Marques,
The answers to your questions are yes, yes.
So what are the questions ???
> My question: Is this behavior expected? Is there a way to configure the argus server so that this does not happen?

So, …, there are a few factors that influence whether argus will track independent flows separately or as a single flow.  The most important are 1) flow descriptors, (i.e. the identifiers used to define the flow) and 2) time.  Argus does not normally use flow state to track flows, because that allows the traffic to influence the behavior of argus, which is not good for dozens of reasons.   Argus normally supports a 5-tuple flow descriptor set, but you can configure it to add any number of objects to that model to get better flow separation.  As an example, Argus uses a 6-tuple flow model for DNS traffic, adding the DNS transaction id to the 5-tuple model, so that it generates a flow record per DNS transaction.  Things like VLAN tags, MPLS labels, can be used to tease out transactions.

Time is used to discriminate 5-tuple flow id reuse for protocols like TCP.  Argus uses specific time based queues that can be tuned to increase or decrease the amount of collisions that may occur.  Argus assumes a flow is active for an ARGUS_FLOW_STATUS_INTERVAL, it then places the flow into a protocol specific timeout queue … if the flow is inactive for this time period, the flow is forgotten.  Most flow collisions, like the ones you describe, occur in the flow idle timeout queue.  The amount of time spent in any of these queues is configurable in the /etc/argus.conf file (or “-F argus.conf” command line option file).

The default status interval and timeout values are based on two estimates, 1) the average flow duration, and 2) an estimate of flow idle time.  

You want the ARGUS_FLOW_STATUS_INTERVAL to cover 2-3x the average flow duration.  Generally, flow durations are under a second, with the exception of video and tunnels, that is why we recommend 1-5 seconds for flow status reporting.  Normally TCP requires that the OS not reuse port numbers for independent TCP, for the TCP_FIN_WAIT_STATE_2 timer, which is normally 60 or 120 seconds.   I don’t think that you have TCP port reuse in under 1 second.  That would pretty much break everything I know about TCP.   Maybe you are seeing port reuse < 20 secs ?????

I would recommend that you shorten your ARGUS_FLOW_STATUS_INTERVAL, maybe around 1-2 seconds, and change the ARGUS_TCP_TIMEOUT value to 10 seconds, or maybe 1/2 the port reuse interval.  If you’re lucky, for these httpperf flows, you maybe able to use a 1.0 second ARGUS_TCP_TIMEOUT value.
Queue timeout values are set as integral values.

You can test this easily with a 1 minute packet capture, and then running argus with a few configuration changes to get the result you want.

Print out stime and dur fields so that we can see what is possible based on these ideas.

If this isn’t working, send me a packet trace of some of you runs, and I’ll noodle through what will work or not.

Carter

> On Jul 15, 2016, at 10:14 AM, Jonatas Marques via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> 
> Hi,
> 
> Context: I've been running three httperf processes in parallel on a 'client' machine to generate workload to a HTTP server running on a server machine. On the server machine I've been running an argus process to record the flows. Because all httperf processes choose their source ports sequentially starting from 1024 and the connection frequencies are *high* (100, 25, 10 connections/s), it may happen that two TCP sessions with the same 5-tuple (saddr, sport, daddr, dport, proto) occur within a short period (~20ms).
> My problem: Argus is generating only one flow record for the two (complete and successfully closed) TCP sessions.
> How do I know: I did a test using wireshark (packet-level monitoring), which maintains the two TCP sessions separated. While for the same test argus generates only one record for both. Test result excerpt:
>     Wireshark output obtained from Statistics/Conversations/TCP
>   saddr sport daddr dport packets  bytes
>       A  1024     B  8000      11   2024
>       A  1024     B  8000      59 108054
>                  ...
> 
>     RA output for ra -n -r my_audit_file.log
>   saddr sport daddr dport packets  bytes
>       A  1024     B  8000      70 110078
>                  ...
>     The sum of packets and bytes from the wireshark flows is equal to the number of packets and bytes in the (one) argus record. 
> 
> My question: Is this behavior expected? Is there a way to configure the argus server so that this does not happen?
> 
> P.S. My test used the ra client to be certain that the cause is the argus server process, but my actual use case requires racluster. Thus, a possible solution must also avoid that the records be joined by racluster.
> 
> Best regards,
> Jonatas Marques

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