argus configuration with upstream router

[Michael Sanderson]

Hi Carter.  Thanks for the response.  I appreciate the effort that you are making so that even the less common configurations will work with argus.

I don't believe that Bidirectional with CLASSIC_5_TUPLE+VLAN is going to help in my case, but perhaps I misunderstand what you mean by "both flow directions share the same VLAN tag".  My internal, routed traffic has different VLAN tags.  Outbound (TX) packet from w.x.y.z to a.b.c.d has VLAN tag Y, but inbound (RX) it will have VLAN tag C.  For Internet traffic, all packets seen between local host w.x.y.z and Internet host h.i.j.k will have VLAN tag Y.

As far as differentiating flows is concerned:  No MPLS.  VLAN tagging is as explained above, so possibly could be used.  Maybe ethernet addresses as well.  The TX packet from w.x.y.z to a.b.c.d will have source MAC M (w.x.y.z) and destination MAC R1 (router).  The RX packet will have source MAC R2 (different from R1, because of HSRP) and destination MAC N (a.b.c.d).  IIRC, on a TX reply packet from a.b.c.d to w.x.y.z, source MAC is N (a.b.c.d) and destination MAC is R1 (because of HSRP). The RX packet will have source MAC R2 and destination MAC M (w.x.y.z).

Would a small packet capture be of assistance?

     Michael Sanderson

On 2013-05-09, at 1:56 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Michael,
> So, this is one of the challenges for carriers, some enterprise
> networks and definitely SDN's, where a single packet maybe on the
> sane wire multiple times, but in different tunnels, or going
> in different directions, whatever.
> 
> I've been working with a few sites to disambiguate these packets so
> we can do the accounting correctly, but ...,  its not easy when there
> aren't any identifiers in the packets to tell us how to do the flows.
> 
> You can currently add the VLAN tags to the flow key definitions, if your
> traffic is separated with vlans.
> 
> Try this in your argus.conf file;
> 
>   ARGUS_FLOW_TYPE="Bidirectional"
>   ARGUS_FLOW_KEY="CLASSIC_5_TUPLE+VLAN"
> 
> As long as both flow directions share the same VLAN tag, all will work
> correctly.  I've got other mechanisms on the way....
> 
> Now, racluster() will put them back together, but I'm working this in
> argus-3.0.7.x so lets get this fixed in argus, then I'll propagate the key
> modifications to the client processing.
> 
> What is there in your packets that can be used to discriminate
> how the flows are tracked?  Ethernet addresses ?  Vlan tags ?
> MPLS labels ? ?????
> 
> Carter
> 
> On May 7, 2013, at 2:11 PM, Michael Sanderson <sanders at cs.ubc.ca> wrote:
> 
>> I'm looking for suggestions of how to configure argus to accurately report traffic in a network configuration where my argus sensor is on my side of an upstream router.  I'm in a University department with multiple subnets on virtual LANs switched internally, but with a tapped link to the University's router.  Something like this, with taps on TX and RX to the argus sensor box.
>> 
>> 
>> SW <-> +-------------------+           +---------------+
>> SW <-> |aggregrator switch |  -> TX -> |router/firewall| -> Internet
>> SW <-> +-------------------+  <- RX <- +---------------+
>> 
>> 
>> My current configuration of argus with ARGUS_INTERFACE=dup:eth0,eth1/uplink results in double counting of local, routed traffic (once on TX and once on RX).  Using bond results in the same thing.
>> 
>> To correct this, I've been thinking of moving to independent interfaces, capturing all traffic on RX to get both local routed traffic and inbound Internet traffic, and capturing only Internet bound TX traffic.  However, I'm not 100% positive this will work.  Is this the right path, and what are the gotchas I should be aware of with respect to ensuring my Internet flows see both src and dst packets?  Is there a better direction to be looking at?
>> 
>> Thanks,
>>    Michael Sanderson
>> 
>> 
>