I'm trying to understand the logic of such flow and I can not even come out with something to explain it. A header only packet? Well it still a packet. A corrupt packet? Again, still a packet.
I don't know what the device is doing nor have access to one to test it. But what I think might be happening is that the device is reporting the flow after "sometime" (an internal timer) but nothing new had happened since the last partial report of it and instead of discarding that information it reports a 0 packet flow. To explain myself a little bit more (using small numbers to describe the idea): Lets say there was a 10 packets flow and that packet number 10 arrived just when the internal timer to report the current active flows was triggered, the router would report those 10 packets. After the next timed period, if there was not other packets over that flow the device will still have the information of it but never cleaned it so it will report it as 0 packets. I don't know if that makes any sense in the real implementation of the JFlow. As a developer this is what I would look first. Another explanations might be an internal counter overflow on either the router or the library. Anyway, to debate your point, if that is what flow-capture receives, that is what it should report. Bugs have to be resolved at their source not at their receivers. The receivers should only make sure they don't crash at invalid data from network devices. I don't believe, in general, software should try to "fix" with "workarounds" bugs from others. They should be powerful enough to detect them and avoid damage and corruption from it. -William On Tue, 2006-05-23 at 10:53 -0700, Mike Hunter wrote: > Hey Team, > > We've installed some new fancy Juniper routers here at UCB. The netflow > experience has been pretty good so far, but I thought I'd share some > wrinkles in case people come up against them in the future. > > The new routers are of vintage: > > Model: m7i > JUNOS Base OS boot [7.4R1.7] > > I've had two problems with them. Problem number 1 was really long flows, > like 4 or 6 hours. There's a knob that is supposed to expire flows after > a set amount of time, but twisting the knob didn't stop the long flows :( > > The second problem was identified today; I got some wacky flows from the > Juniper that have 0 packets and octets: > > Start End Sif SrcIPaddress SrcP DIf > DstIPaddress DstP P Fl Pkts Octets > > 0521.23:12:55.315 0521.23:28:07.795 55 169.229.123.123 32862 56 > 192.58.123.123 53 17 0 0 0 > > That causes flow-stat to freak out a bit: > > ... > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > Ignoring bogus flow dPkts=0 > ... > > Does anybody have a strong opinion about writing logic into flow-capture > to discard such flows? I'm not offering a patch, just trying to spur > debate :) > > Mike > _______________________________________________ > Flow-tools mailing list > [EMAIL PROTECTED] > http://mailman.splintered.net/mailman/listinfo/flow-tools _______________________________________________ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
