----- Original Message ---- From: Ed Ravin <[EMAIL PROTECTED]> To: jay alvarez <[EMAIL PROTECTED]> Cc: [email protected] Sent: Thursday, January 4, 2007 11:55:04 AM Subject: Re: Illegal Attempt to update using time...(Re: No graphs created after flow-capturing a month)
On Wed, Jan 03, 2007 at 07:28:53PM -0800, jay alvarez wrote: > > And it was a chain reaction... all flows being processed since Dec 1, > > 2006 5:30PM up to present keeps on (or most of the time) throwing the > > same error, resulting to empty badly needed graphs. :-( > Is it the same error message with the same "last update time" value, on > all subsequent messages? If not, what's there? ft-v05.2006-12-01.175500+0800 is good, same as with: ft-v05.2006-12-01.180000+0800 upto 1815. Then the error appears again while attempting to process 1820 flow: using 1164967500 (Fri Dec 1 18:05:00) when last update time 1164967800 (Fri Dec 1 18:10:00) Then 1825 is good and also 1830. Then an error again on 1835: using 1164968400 (Fri Dec 1 18:20:00) when last update time Fri (Dec 1 18:30:00) 1840 to 1905 is also good. Then 1910 is bad. (Fri Dec 1 18:55:00 / Fri Dec 1 19:05:00) 1915 to 2035 are good. 2040 bad. (Fri Dec 1 20:30:00/ Fri Dec 1 20:35:00) 2045 to 2135 are good. 2140 bad. 2145 to 2200 are good. 2205 to 2215 bad. 2220 to 2250 good. ... Any idea what can we conclude with this? > Run the "flow-header" command on a flow file to see the timestamps of > the data within. That might shed some light on things. Running flow-header on a good flow let's say 1915 gives me: # # mode: normal # capture start: Fri Dec 1 19:15:00 2006 # capture end: Fri Dec 1 19:20:00 2006 # capture period: 300 seconds # compress: on # byte order: little # stream version: 3 # export version: 5 # lost flows: 58 # corrupt packets: 0 # sequencer resets: 0 # capture flows: 163753 while on a bad flow, say 2040 gives me: flow-header < /var/netflow/ft/all/ft-v05.2006-12-01.204000+0800 # # mode: normal # capture start: Fri Dec 1 20:40:00 2006 # capture end: Fri Dec 1 20:45:00 2006 # capture period: 300 seconds # compress: on # byte order: little # stream version: 3 # export version: 5 # lost flows: 0 # corrupt packets: 0 # sequencer resets: 0 # capture flows: 163000 What does this tell? > It would be a good idea to make sure your router and collector host > are both synchronized to the correct time. Turn NTP on in your router > if it's not already there, and make sure the timezones are also in > agreement. Yep, they were already configured them to do so long time ago. But I will have to check on this. > Also, do some web searching if you haven't already, especially on the > FlowScan list - this problem sounds very familiar. Just bumped into this: https://www1.columbia.edu/sec/bboard/mj/cuflow-users/archive/2003_07/msg00019.html but his case was different, having last update time same as the one he is trying to add.. Also this one: https://www1.columbia.edu/sec/bboard/mj/cuflow-users/archive/2005_08/msg00004.html Not a problem of machine lagging behind.. Cflow::find only takes 15 wallclock secs on the average.. Neither a case of disappearing flows.. I don't know where else to look into. I'll try raising this issue to flowscan and CUFlow list and see if I can get something useful. Then I'll get back to this list for the rest of new users to have a reference if in case they encounter the same problem in the future.. Thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
