​ Netflow - Direction field in argus?

[Carter Bullard]

Hey Sebastian,
Argus is a bi-directional flow monitor, and the flow
direction indicators are based on a specific connection
oriented data model that is designed to determine who is
the initiator of the TCP connection. This distinction allows 
you to know which port is the service port and which is the
ephemeral port in the flow record. 

Because most Internet protocols have packets that are going in
both directions, the direction of the flow is not determined
by the direction of the packets, as that would always be
" both ", which is not a direction.  Argus's flow direction
is based on the direction of the first packet observed.  And
then for connection-oriented protocols, like TCP, we provide
originator status information, so the clients can correct
for direction when needed.

Netflow does not provide enough information to make a definitive
determination of who initiated TCP establishment.  Netflow or's
the TCP flags throughout the life of the TCP flow, and so you
cannot know who sent the SYN, nor who sent the SYN_ACK, when
the connection transfers data and there are lone ACK packets
on the path.  The resulting flags field will both have SYN_ACK
indications, minimally.

Because netflow is a uni-directional flow system, when we print
a netflow record, the src and dst identifiers in the resulting
argus records will be in the same direction as the original
record sent by the Cisco box. (if you think this isn't correct,
send more mail !!!).  But because V9 provides ingress and egress
mapping, we tally the netflowV9 data type k_CiscoV9InBytes
and k_CiscoV9InPackets as source metrics, and k_CiscoV9OutBytes
and k_CiscoV9OutPkts as dst metrics.

To test this, print the " spkts " field and the " dpkts " field,
rather than " pkts ".  See if you see the metrics shift from
src to dst.

The ingress and egress indicators are usually used to map L2
identifiers, such as ethernet addresses, so if your records are
providing k_CiscoV9InDstMac or k_CiscoV9OutSrcMac then the
direction can be used to assign mac addresses to the argus
flow record we generate.

Aggregating argus-client programs, like racluster(), will combine
two uni-directional netflow records that represent the two directions
of a single TCP.  There are a few conditions where the direction of
the resulting bi-directional flow records can be determined, and so
some bi-directional records may have their directions modified.
However, when the direction cannot be determined, the assignment of
source and destination will be based on the first record received.

If something doesn't make sense, or doesn't work you, holler, and
we'll fix it !!!!!

I'm assuming you're using argus-clients-3.0.7.x code?

Carter


On Jun 13, 2013, at 8:31 AM, Sebastian YEPES FERNANDEZ <syepes at gmail.com> wrote:

>  Hello,
> 
> We have configured in one of our Cisco Routers the forwarding of Netflow v9 stats ​in ​both ingress and egress modes of one physical interface. we have verified using tcpdump/Wireshark that the received packets have the direction field correctly set depending on the traffic. (0 = ingress flow, 1 = egress flow)
> 
>  The issue is that once we have collected the Netflow records into the Argus format we are not able to see the direction of the packets we see many ? and ?>.
> 
> ​- Does anyone have experience with this kind of setup?​
> ​- How can we clearly distinguish between ​ingress and egress flows using the ra* tools?
> 
> 
> 
> ​The setup:
>  Version: argus-clients-3.0.7.9.tar.gz
> 
> # cat /opt/argus/radium.cfg
> RADIUM_BIND_IP=10.x.x.x
> RADIUM_DAEMON=no
> RADIUM_CISCONETFLOW_PORT=9996
> RADIUM_ACCESS_PORT=561
> RADIUM_MAR_STATUS_INTERVAL=60
> 
> # /opt/argus/bin/radium -f /opt/argus/radium.cfg
> # /opt/argus/bin/rasplit -S $(hostname) -M time 1d -w /opt/argus/data/archive/%Y/%m/data.%Y-%m-%d
> # /opt/argus/bin/ra -R /opt/argus/data/archive/2013/06 -M rmon -s saddr sport daddr dport proto trans pkts bytes dir
> 
>               Host  Sport            DstAddr  Dport  Proto  Trans  TotPkts   TotBytes   Dir
>          10.x.x.x.snmp          10.y.y.y.19940     udp      1        2        440    ->
>      10.x.x.x.19940            10.y.y.y.snmp      udp      1        2        440   <-
>    10.y.y.y.4816           10.x.x.x.http      tcp      1        2        198    ?>
>  10.x.x.x.http       10.y.y.y.y      tcp      1        2        198   <?
>  10.x.x.x.http       10.y.y.y.y      tcp      1        2        20   ?
>  …
>  …
> 
> 
> ​Thanks in advance for any help.​
> 
> 
> B ​est regards,
> Sebastian​

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