Hi Rod, As classification of the log messages suggests, the only to worry about is the last one, which is a warning.
For all the INFO/DEBUG messages you better off starting from the docs/INTERNAL document, part of the standard distribution tarball. Should you have any further questions, will be more than happy to answer them. With regards to the warning message: that's precisely as you got it. Either packets arrive out-of-order or they are lost prior to delivery to nfacctd. By scanning the log message, it should be feasible to spot cross-references which would imply the out-of-order case. If you drill it down to the case where packets are lost prior to being delivered to nfacctd, this can be due to the router, network or the underlying OS. If unsure, you can always stick in parallel to nfacctd, say, a Wireshark to double-check whether packets with missing seq numbers it to the OS or not. Cheers, Paolo On Thu, May 20, 2010 at 02:47:17PM +0200, Oliver, Rod wrote: > Hi All, > > I am a new user of nfacctd & pmacct. I have it installed in a lab environment > for the purpose of determining whether hardware and software supports Netflow > properly and to assist in finding appropriate configuration of that > equipment. I'm running nfacctd with a very simple configuration file and > using the memory plugin. While developing the test procedure I've found that > the memory database is not being filled with records as I would expect given > the deterministic flows that I'm sending through the device under test when > the number of records is slightly on the heavy side. It seems that records > are getting lost prior to inserting into the db. I'm wondering whether > records are being lost on arrival at nfacctd. > > I have configured the debug directive to true and have seen a few log > messages written that I don't understand that suggest (to my ignorant self) > that not all is well with nfacctd. I list examples of them below. I would > appreciate pointers to their meaning and if they indicate problems, what I > should/could do to fix them. > > INFO ( default/memory ): 129024 bytes are available to address shared memory > segment; buffer size is 136 bytes. > INFO ( default/memory ): Trying to allocate a shared memory segment of > 2193408 bytes. > DEBUG ( default/memory ): allocating a new memory segment. > Is this an indication that insufficient memory can be allocated to nfacctd? > > > DEBUG ( default/memory ): using an already allocated memory segment. > Is this an indication of an attempt to write in already occupied/used memory? > If so what happens to the contents of the memory location or that which was > attempted to be written to that location? > > DEBUG ( default/memory ): Selecting bucket 13803. > DEBUG ( default/memory ): Walking through the collision-chain. > > WARN: expecting flow '19261' but received '19263' collector=0.0.0.0:2200 > agent=10.15.186.131:2049 > Does this imply either record packet re-ordering or loss? > > Rod Oliver > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
