Thanks Hadriel,
I will pass the release number into the functions that deal with
sequence numbers. Will probably hide sequence number analysis behind
a preference setting, defaulted to on for now. r10 does sound as
though it is back to something identical or similar to flows again.
Martin
On Sat, Jul 4, 2015 at 9:26 PM, Hadriel Kaplan <hadrielk@xxxxxxxxx> wrote:
> Since Netflow v9 is a Cisco-defined protocol, their own docs should arguably trump the IETF RFC for their protocol. (personally I would read that RFC to mean the number of packets/frames, not number of flows)
>
> According to this:
> http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html
>
> ... the sequence number in Netflow v9 represents the number of export packets (i.e., frames for Wireshark); whereas in previous Netflow versions it represented number of flows.
>
> That is corroborated by this:
> http://www.cisco.com/c/en/us/td/docs/net_mgmt/netflow_collection_engine/3-6/user/guide/format.html
> which said for v5-v8 it was number of flows.
>
> Looking at some captures of Netflow v9 from old bug submissions, it appears to be number of packets - including if the packet only contained a Template.
>
> So perhaps you’re looking at captures with different Netflow versions?
>
> Or maybe you’re looking at version 10 (i.e., IPFIX), which defines the sequence number as the number of Data Records, so neither packets/frames nor flows really. (though from our internal code's perspective, I guess they would be “flows")
>
> -hadriel
>
>
>> On Jul 4, 2015, at 9:27 AM, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
>>
>> (I think my previous attempt to send this failed, so resending)
>>
>> A few months ago I updated the Netflow dissector to do sequence
>> analysis using the Sequence Number field within an Obvservation
>> Domain, based upon RFC 3954 and a capture file I was looking at.
>>
>> RFC 3954 describes the field as follows:
>>
>> Sequence Number
>> Incremental sequence counter of all Export Packets sent from
>> the current Observation Domain by the Exporter. This value
>> MUST be cumulative, and SHOULD be used by the Collector to
>> identify whether any Export Packets have been missed.
>>
>> A Netflow frame has the Obvervation-domain + Sequence number at the
>> top, then a number of flows below. What is not clear to me is whether
>> this field should advance by the number of flows in this frame, or the
>> previous frame.
>>
>> The capture included in this bug report
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11047 increments
>> according to the number found in the previous frame for this
>> Obvervation domain (i.e. it represents the SN at the beginning of the
>> current frame).
>>
>> Whereas a different capture I was looking (when the sequence analysis
>> was written) increments according to the number of flows in this frame
>> (i.e. it represents the SN at/beyond the end of the current frame).
>>
>> Could someone with a working knowledge of Netflow put me right? Is
>> there another spec where the usage of this field is made clear? Are
>> both approaches valid?
>>
>> Thanks,
>>
>> Martin
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe