simple question

Carter Bullard carter at qosient.com
Thu May 7 12:53:28 EDT 2009


Hey Peter/Rodney,
We silently ignore printing a field that isn't in a particular argus  
record,
and print a pad (if needed).  One reason, is that we could be processing
records from different probes at the same time (for correlation  
purposes,
whatever) and not all probes are going to be configured the same.
Also, post processing of records could remove or invalidate a field, so
no reason to stop processing or generate a warning/error.

Carter

On May 6, 2009, at 11:30 PM, Peter Van Epp wrote:

> On Wed, May 06, 2009 at 03:52:07PM +1000, Rodney McKee wrote:
>> Alexander,
>>
>> As Peter mentioned, the thing that I was missing was the recording  
>> of MAC addresses.
>>
>> ARGUS_GENERATE_MAC_DATA=yes
>>
>> Make sure this is enabled on the server otherwise its a more  
>> complex process.
>>
>>
>
> 	Did it toss an error message or warning anywhere when you didn't have
> MACs enabled? I'd think (but would have to look at the code to be  
> sure) that
> ra should be able to detect that the MACs aren't in the record  
> (either because
> the DSR isn't present, or the MACs are 0ed) in which case if there  
> is a MAC
> based filter present a warning that there is no MAC data to filter  
> on would
> be a useful enhancement I expect. The devil may be in the details of  
> compiling
> the BPF filter before actually processing the data to know whether  
> there are
> MACs present or not though.
> 	As well the ra output should tell you that the filter is working
> correctly as all the source addresses should be from your network IP  
> range
> and all the offsite ones should be destinations. Its probably worth  
> noting that
> if you are single arm routing between VLANs argus will be confused  
> as it is
> selecting on 5 tuples (not VLAN ID which would be a 6 tuple) and  
> thus will
> aggregate the same packet on the 2 VLANs in to one (because the 5  
> tuples match).
> 	Finally tcpdump/wireshark/sniffer are your friend. If you can capture
> a pcap file from your network (or alternately let argus write a pcap  
> file which
> is another .argusrc option although it has performance issues) you  
> can use
> tcpdump/wireahark/ a sniffer to manually parse the pcap file and  
> compare the
> results to what ra produces. argus will happily accept a pcap file  
> with the -r
> option and write an argus file just as if it came in from an  
> interface but
> with reproducable (we hope anyway :-)) results. Due to the reporting  
> interval
> the ra output won't be identical, but if you sum them all up (I  
> typically use
> perl for that) the totals should always match and should match the  
> manually
> parsed tcpdump output. I've also used tcpreplay to replay a pcap  
> file to the
> physical interface (and may do so again if I find I need more  
> traffic than I
> have and can get a suitable capture from SFU or more probably the  
> local Gigapop
> who have a 10 gig capture applience).
>
> Peter Van Epp
> analysis.
>

-------------- 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/20090507/438d93d1/attachment.bin>


More information about the argus mailing list