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 <hadri...@yahoo.com> 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.mathie...@googlemail.com> 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@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
