[ARGUS] QoS Analysis with Argus

[Peter Van Epp]

	The first thing that strikes me is that you have multicast running
across the link. Unless that is intentional (i.e. the far end is multicast
enabled and you are using multicast) filtering multicast out (i.e. 
deny 224.0.0.0/4 in your router) may help some. Same with the unroutable 
addresses (again unless there are unroutable addresses on the far side of 
your link which is possible) if you filter 192.168.0.0/16 for both source
and destination before the link on both ends that traffic will remain local
as it should and not eat link bandwith (this may be broadcast traffic being
sent to the link although I didn't see any .255 addresses on a quick scan).
	As someone else pointed out your performance issue will be the large 
gray spike that is showing a 120K sustained rate at 14:30 to 15:15 or so. At 
that point the link is saturated and you will see an exponential rise in delay 
as traffic queues to get on the link. Now you need to use ra with the -t
option to select the traffic from 14:30 til 15:15 or so and see who is using
the bandwith and what they are doing (by looking at the destination port 
numbers). From some of the addresses I expect some of the traffic is likely
port scans and virus traffic which will be hard to supress, but you may find
someone doing a large ftp for instance that is saturating the link. 
	Another useful tool is a perl script which eats ra output and spits
out a traffic report in reverse numeric order by traffic like this (the counts
are corrected to being in link order as well so From: is one side of the 
physical link and To: is the other side which is not necessarily true of ra
output because argus declares "source" as the end that started the session
not necessarily line order). The script the output below is from isn't finished
yet, but there is an earlier version available in the list archives somewhere.
	This indicates that our web server is as always our busiest after 
that are the remote addresses followed by the traffic by port so you can 
see where the load is coming from.

142.58.200.82   Total: 1,457,457,170    From: 1,386,207,653    To: 71,249,517

  24.69.255.242   total: 108,343,977      From: 105,637,618      To: 2,706,359
    80      From: 105,637,618      To: 2,706,359
  24.86.48.149    total: 94,594,959       From: 91,945,017       To: 2,649,942
    443     From: 91,933,258       To: 2,641,433
    80      From: 11,759           To: 8,509
  24.87.240.164   total: 77,731,897       From: 75,650,445       To: 2,081,452
    80      From: 75,650,445       To: 2,081,452
  24.87.254.225   total: 36,082,312       From: 35,110,915       To: 971,397
    80      From: 35,110,915       To: 971,397
  203.218.232.114 total: 35,972,088       From: 35,065,528       To: 906,560
    80      From: 35,065,528       To: 906,560
  24.85.111.249   total: 35,352,579       From: 34,591,632       To: 760,947
    80      From: 34,591,632       To: 760,947
...

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

On Wed, Jul 07, 2004 at 10:34:18PM +1000, James Lever wrote:
> Hi All,
> 
> I'm trying to perform some quality of service analysis with Argus to 
> determine true cause of network slow-downs.
> 
> I've so far determined times/dates of high traffic 
> (bytes+daddr/saddr/dport) and have also used the packets metric to 
> cross-check.
> 
> The link I am concerned with is a single/dual channel ISDN (2x 64kBps B 
> channels) running single channel most of the time and bursting up to 
> dual channels in times of high demand.
> 
> Can somebody give me an idea of what loss could be expected on such a 
> link before a noticeable degredation of service was noticed?
> 
> Also, what is jitter?  My best guess is time between an outgoing packet 
> and an incoming packet.  What should be expected?  How many orders of 
> magnitude difference would be required to have a perceived massive 
> degredation of service?
> 
> Some graphs of interest are currently available at 
> http://jamver.id.au/argus/ if anybody is willing to have a look and 
> give me some ideas on directions to look.
> 
> How would you try to analyse QoS using Argus?  Would you use other 
> tools too?
> 
> cheers,
> James