argus configuration with upstream router

[Carter Bullard]

Hey Michael,
Sorry for the delayed response.  I thought I had sent something, but
this email was in my Drafts folder, for some time….sorry !!!

Sure packets are always useful.

So, for the router to support the ingress and egress packets for Host X,
which is in VLAN Vx, both directions of traffic between the router and the host
should be in the same VLAN.  For traffic that maybe on the same wire,
but going in another direction, or to another system, such as an upstream
router, either the VLAN will be different, or the ethernet addresses involved
in the flow will be different.

In any case, if you do CLASSIC_5_TUPLE+VLAN, you will stop the double
counting.  Where the VLAN tags are the same, say in the end system itself,
you will get bi-directional flows.  For the first hop switch, you should still be
getting bi-directionality, but as you move away, the VLAN tags may not match.

We can add logic to argus to say that traffic in these two VLANs belong, and
these others don't….  Not sure if there is an opportunity that will satisfy all
conditions.

When argus can't get them together, we'll have to provide some hints to
the client aggregation configuration that tells the clients which VLANs
should be merged and which shouldn't.

These extensions will need to be developed.

I have an argus that supports adding Layer_2 identifiers to the flow key, which
has helped to disambiguate packets, if the VLAN tags don't do the trick.
But as you pointed out, that doesn't work that well either, unless we say that
these 2 ethernets are equivalent, …….

Carter 

On May 10, 2013, at 2:08 PM, Michael Sanderson <sanders at cs.ubc.ca> wrote:

> 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
>>> 
>>> 
>> 
> 
> 

-------------- 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/20130513/be955fc0/attachment.bin>