argus-3.x request (forwarded)

Carter Bullard carter at qosient.com
Thu Feb 11 11:59:27 EST 2010


Hey Peter,
Do you have (or did you have) any packets that express this problem
where the same flow is on the wire multiple times, but in different tunnels?
I'm starting to think about a general solution, but could use some packets
to help me ponder the problem.

Carter

On Jan 25, 2010, at 9:26 PM, Peter Van Epp wrote:

> 	Timely reminder :-) I was meaning to put mt $.02 in and forgot :-). 
> It may be on the list somewhere (we talked about it a fair while ago), adding
> vlan (and now probably mpls) tags to the tuple would be useful in one armed
> routing situations. Running argus on an interface that is one armed routing
> between VLANs or secondary interfaces used to break (and I expect still does
> although I haven't tried it in a long time). Argus used to get confused by 
> seeing the same traffic on different VLANs (because it was ignoring the vlan
> tag). The fix of course was "it hurts when I do this, so I don't do that 
> anymore" which worked in my particular case but probably won't always do so. 
> 
> On Mon, Jan 25, 2010 at 12:52:29PM -0500, Carter Bullard wrote:
>>> Hey Martin,
>>> You should be using argus-3.0!!!  Or at least be playing with it ;o)
>> 
>> Yes I know. :-)
>> We're upgrading to 64bit "soon" and then we'll upgrade all argus daemons and
>> ra*-utilities.
> 
> 	3.0 will work fine on 32 bit machines, it is only required for 64, so 
> is the issue the work to install twice (which I could quite understand)?
> 
> <snip>
>>> The problem is that
>>>           with this strategy you capture 256 bytes of every flow, and
>>> that maybe an issue for
>>>           some sites.
>> 
>> Ah, yes that would fill the HDDs quite quickly.
>> 
>> ...or wait, did you say flow.   Will only 256 bytes (from the first few
>> packets) be logged? Doh! I assumed it acted like 'tcpdump -s 256'.
>> 
> 
> 	It does at the pcap level because pcap doesn't keep state (argus is 
> doing that) and there isn't feedback nor currently a mechanism to implement
> it. So the capture card has to capture and transfer to the host (which is where
> the usual bottleneck is) around 300 bytes per packet. On high speed links 
> (gig and higher for sure) that load can become crippling especially if you 
> aren't using one of the memory mapped zero copy pcaps to cut down on memory
> bandwidth. Argus will happily toss the user data from all except the first 
> packets in the flow, but the data is still burning memory bandwidth until
> argus discards it. 
> 
> Peter Van Epp
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100211/39444057/attachment.bin>


More information about the argus mailing list