FW: Argus V2.0

[Peter Van Epp]

> 
> Hey Peter,
>    Here's a copy of my mail from this morning.
> The length of the options is limited so we
> should be able to pick a minimum snap length
> that will get us everything that we need, say
> 128 bytes, or 96 or something that makes sense.
> This will make Argus a little more useful for
> some QoS stuff as well.

	That would be best I expect. From my limited playing with tcpreplay 
(which I hope will accelerate now I have 5 600 meg P3s to play with) it looks
like capturing full length packets is going to be the performance limit. I
appear to be able to source them from disk to the wire at full speed at 100
(although the file was only 50 megs or so long and there is 128 megs of ram in 
the machine and I may have been coming out of VM). I have 40 gig UDMA66 disks 
and controllers in the new machines so I can try large files and see if the 
speed maintains (and try full duplex). The capture process was losing
packets at a relatively light traffic time (of course it was also running
argus at the same time which might not have helped). I intend on poking at 
which is faster FreeBSD or OpenBSD and if I can convince either (or something
custom) to capture at full speed 100. I don't like any of the hundred full
duplex sniffers that I have seen (nor the cost) and I'm thinking a build your
own that can export capture files to our current sniffer may be the answer.

> 
>    I'm interested in using Argus records to drive
> tcpreplay along with something like udpreplay and
> icmpreplay to replay an entire days worth of
> network traffic.  Products like SmartBits do OK
> simulating traffic, but with an Argus audit
> trail, you could play back real traffic into test
> networks, rather than simulated stuff.  This should
> be pretty easy to do?

	I'd expect so. It also gets around the pesky problem of data privacy 
(since I expect you'd fill the data field of the packet with random data).
I've been thinking about how I could sanitize the data of captured packets
from the network to be able to release real network traces. One of tcpreplay's
modes is transmit the packets at the rate that tcpdump says they were 
received (rather than at a fixed rate which is primarily what I have been
using to characterize performance) so the stuff should be all there to do 
large, long real traffic reproductions. 
	An editor that would let you edit packets in the tcpdump file
would also be a useful thing (allowing you to introduce errors for instance).
I expect given the potential size of the files, an edit in place scheme that
accumulates changes in a log file then increases the size of the file (in place)
to accomidate the changes and starts from the end of the file moving data to
the new end of the data and inserting changes from the log file in to the file
as the correct position comes by would be the way to go here (sort of an 
interactive sed). With large fast cheap IDE disks (my 40 gig ones were around
$500 Canadian and now are down to $350 or so) this should be easily doable.
with the amplification from an argus log (rather than a complete capture) 
it should get even better. I have some suspicion (although I have to run some
disk benchmarks to find out) that full duplex would need two (and possibly
a third one for the OS) IDE channels to pump the data. I've already discovered
our sniffer starts silently losing packets at about the 10 meg level (when
it is supposed to be able to do around 70 megs or so). I have a Cabletron
router in the middle and it sees the correct number of packets out of the 
tcpreplay box (indicating both of them are keeping up) but the sniffer loses
a bunch.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada