[PATCH] TcpRtt support in ragraph

Carter Bullard carter at qosient.com
Tue Aug 26 08:56:50 EDT 2008


Not noise at all!!!    Detecting proxies along the path is one of the
reasons we have TcpRtt in the argus metrics.

Any idea how to get packets before they make it to the pf?  Nice to get
the protection offered by "TCP SYN Proxy" or the "Spoofed Packet
Blocking", but it would be nice to monitor the packets before the
pf does stuff to them?

Hope all is most excellent, and I'm glad argus is working for you.

Carter


On Aug 25, 2008, at 9:12 PM, Tomoyuki Sakurai wrote:

> On Mon, Aug 25, 2008 at 07:36:17PM -0400, Carter Bullard wrote:
>>
>> Hi,
>> TcpRtt is actually calculated as the complete round trip time
>> measured as the syn->synack times "+" the synack->ack time.
>> Even if argus is in the middle, you will get a full roundtrip time
>> calculated, but you have to see all three packets in order
>> to calculate the metric.  Its possible that you have asymmetric
>> paths for the TCP data?
>
> No, the path is symmetric and argus sees complete TCP stream. But your
> suggestion made me think again and I understood why. In short, argus  
> is
> right, it was pf on OpenBSD router that made TCP handshakes.
>
>> Because the TcpRtt is the sum of two other metrics, you can
>> print the two components and the totals to see where its messing up.
>>
>>    ra -r file -s +synack +ackdat +tcprtt - tcp
>
> "ra $OPTIONS - tcp and not src net $MYNET" shows:
>
> Proto sCo   Dir dCo State  SynAck(Sec)  AckDat(Sec)  TcpRtt(Sec)
>  tcp  JP    ->  JP  sSEf     0.000169     0.000097     0.000266
>  tcp  US    ->  JP sSEfF     0.000143     0.000101     0.000244
>  tcp  CN    ->  JP sSEfF     0.000233     0.000098     0.000331
>  tcp  RU    ->  JP sSEfF     0.000165     0.000098     0.000263
>  tcp  KH    ->  JP sSEfF     0.000236     0.000105     0.000341
>  tcp  GB    ->  JP sSEfF     0.000122     0.000100     0.000222
>  tcp  DE    ->  JP   sSE     0.000255     0.000102     0.000357
>  tcp  SG    ->  JP  sSEf     0.000155     0.000102     0.000257
>  tcp  TH    ->  JP sSEfF     0.000131     0.000101     0.000232
>  tcp  MY    ->  JP sSEfF     0.000133     0.000104     0.000237
>
> These would be impressive RTTs if they were real :)
>
> I had "pass ... synproxy state" in pf.conf. That means pf was proxying
> initial TCP handshake for the client and then argus saw the packets.
> After disabling synproxy keyword, argus sees unmodified TCP handshake.
>
> Proto sCo   Dir dCo State  SynAck(Sec)  AckDat(Sec)  TcpRtt(Sec)
>  tcp  US    ->  JP  sSEf     0.000279     0.142032     0.142311
>  tcp  JP    ->  JP  sSEf     0.000216     0.119915     0.120131
>  tcp  JP    ->  JP  sSEf     0.000246     0.119765     0.120011
>  tcp  US    ->  JP sSEfF     0.000158     0.203272     0.203430
>  tcp  JP    ->  JP sSEfF     0.000253     0.045925     0.046178
>  tcp  TH    ->  JP sSEfF     0.000134     0.183594     0.183728
>  tcp  EU    ->  JP sSEfF     0.000224     0.281545     0.281769
>  tcp  JP    ->  JP sSEfF     0.000208     0.018305     0.018513
>
> Now that the result is reasonable.
>
> If you are using synproxy, place the argus where unmodified packets  
> can
> be seen, like in front of OpenBSD host. You'll still miss RTT between
> the OpenBSD router and dst host, but in most cases, it wouldn't be a
> problem since the missed RTT would be a few msec.
>
> Sorry for the noise.
>
> -- 
> Tomoyuki Sakurai
>




More information about the argus mailing list