Argus management records

[Carter Bullard]

The dropped packets are reported by the libpcap interface, so you won't see them using ifconfig.  Why there are reported  drops is not always clear, but if it is chronic, you may need to modify something, either more machine, not having argus write to a file, etc .....

You should be able to graph it using "drop" but "sport" should do it too?

Carter

 


Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

-----Original Message-----
From: "Esteban G" <infoape at gmail.com>

Date: Wed, 14 Nov 2007 11:13:34 
To:"Carter Bullard" <carter at qosient.com>
Cc:Argus <argus-info at lists.andrew.cmu.edu>
Subject: Re: [ARGUS] Argus management records


Thanks for the response Carter. Just want to say that  your work is
great and I really appreciate the efforts.

I didn't realize the management records were quite so rich. Out of
curiosity I started going through them  for some of my collectors and
was surprised to see some "packets dropped". Should I see a similar
indicator of dropped packets in the output of ifconfig?

Also is this the correct command for graphing dropped packets:
ragraph sport -M 5m -r argusfile.gz  -title  "Dropped PAckets" - man

-Esteban

On Nov 12, 2007 7:40 AM, Carter Bullard <carter at qosient.com> wrote:
> Hey Esteban,
> Sorry for the delayed response.
> The man records contain the state of the probe, and we generate
> these every ARGUS_MAR_STATUS_INTERVAL, which is every
> 60 secs by default, ( you can specify another time in the argus.conf ).
> The clients use these are keep-alives, so that they know that their
> source of data is still there, whether it is generating FARs or not.
>
> The contents of the 128 byte management record currently are/is:
>
>     unsigned int status, argusid, localnet, netmask, nextMrSequenceNum;
>     struct ArgusTime startime, now;
>     unsigned char  major_version, minor_version, interfaceType,
> interfaceStatus;
>     unsigned short reportInterval, argusMrInterval;
>     unsigned long long pktsRcvd, bytesRcvd, timedrift;
>
>     unsigned int records, flows, dropped, queue, output, clients;
>     unsigned int memorybufs, memorybytes;
>     unsigned short suserlen, duserlen;
>     unsigned int thisid, record_len;
>
> and the purpose is to expose/externalize the key aspects of
> the performance of the argus/radium.
>
> Many of the objects are identification oriented, argusid, localnet,
> netmask, major_version, minor_version, interfaceType,
> FarReportInterval, MarReportInterva, suserlen, duserlen, and
> all help the clients to know what to expect, and if anything has
> changed with regard to the probe itself.
>
> The rest of the objects are metrics, and can be important.  They
> include:
>     startime, now;  (reporting interval for this man record)
>     pktsRcvd, bytesRcvd (probe load)
>     timedrift (perceived drift from correct time, usually
>                     supplied by radium/ra* programs).
>     records (number of records written out)
>     flows     (total number of flows tracked)
>     dropped (number of input packets dropped by engine)
>     queue    (current number of flows being tracked)
>     output    (current number of records scheduled to be written)
>     clients    (number of registered output clients)
>     memorybufs (number of buffers allocated)
>     memorybytes (total number of bytes allocated)
>     suserlen, duserlen (max user buffer capture size)
>
>
> from this data you should be able to tell if the argus/radium is
> healthy or not.
>
> When you print the contents of the mar record using ra*, the
> fields are mapped like the list below.  There is no real justification
> for this, and so if you have a better way of mapping the Far and
> Mar Fields, please make suggestions, before the release!!!
>
>     stime  startime
>     ltime   now
>     flgs     blank
>     proto  'man'
>     saddr  "queue count"
>     sport   "packets dropped"
>     dir      blank
>     daddr  "memory bufs"
>     dport  "registered clients"
>     spkts  "pkts received"
>     dpkts  "records written"
>     sbytes "bytes received"
>     dbytes "memory bytes"
>     State   "status"
>
>
> I know that these seems like chaos, so if you have any
> suggestion as to how to overload this, that would be great.
>
> Carter
>
>
>
>
> On Nov 8, 2007, at 2:55 PM, Esteban G wrote:
>
> > sorry meant to include the paste of the ra command:
> > ra -L0 -n -r <argus file> - man
> >
> > -esteban
> >
> >
> > On 11/8/07, Esteban G <infoape at gmail.com> wrote:
> >> Just out of curiosity what are we looking at when we see these
> >> records:
> >>
> >>          StartTime    Flgs  Proto            SrcAddr  Sport   Dir
> >>       DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes
> >> State
> >>    00:01:02.164051            man               1412      0
> >>          5930      1    44205     1625     18052533      3825435
> >> CON
> >>    00:02:02.168611            man               1835      0
> >>          7219      1    47569     3029     17959596      7166675
> >> CON
> >>    00:03:02.173056            man               1696      0
> >>          6968      1    61118     3603     30275159     10517483
> >> CON
> >>
> >>
> >> -esteban
> >>
> >
>