grarpamp at gmail
Dec 27, 2010, 8:15 PM
Views: 224
Permalink
|
|
Nprobe Bug - Incorrect packet headers in V9 and V10 exports
|
|
While checking into Ben's now resolved "nprobe 6 and engine id"
issue of Dec 21, I found four bugs and am reporting them separately.
If someone can send me the next tarball of nprobe..proplugins.tgz
that comes out so that I may continue to find and report bugs, that
would be awesome! Thank you all and have a great New Year, GP :)
### Bug Number One: Nprobe - Incorrect packet headers in V9 and V10 exports
I dumped the header fields coming from nprobe...
Using -V5 -E 65:66, this is correct.
Cisco's doc's differ depending on which you read. I'm using V5 in
places, and it's been a while since I checked a real Cisco export
packet, but this feels right.
00000000 00 05 00 04 00 00 29 23 4d 12 67 46 00 00 02 4e
00000010 00 00 00 00 41 42 00 00
Using -V9 -E 65:66, this is incorrect.
According to Cisco, this should be 00 00 41 42.
00000000 00 09 02 01 00 00 25 3e 4d 12 67 d8 00 00 00 00
00000010 41 00 00 00
Using -V10 -E 65:66, this is incorrect.
According to Cisco, this should be 00 00 41 42.
00000000 00 0a 01 8c 4d 12 72 8e 00 00 00 00 00 00 00 42
Note that the actual V9 and V10 records do appear to have the
"%ENGINE_TYPE %ENGINE_ID" embedded further on in. It's the header
that seems broken, which could definitely confuse some parsers.
For the fix, you'll probably need to address the byte order and
then concatenate both the type and id into that field. Around:
export.c 877 v9Header->sourceId = readOnlyGlobals.engineType; /* CHECK */
export.c 886 v10Header->observationDomainId = htonl(readOnlyGlobals.engineId);
Here are the definitions in question for reference...
# RFC V10
http://www.rfc-editor.org/rfc/rfc5655.txt
The ObservationID is defined here, by implied reference to the next
document below.
- Observation Domain ID: Similarly, the NetFlow V9 sourceID has
become the IPFIX Observation Domain ID.
- Export Time and Observation Domain ID taken from the UNIX
secs and Source ID fields of the NetFlow V9 packet header,
respectively.
# RFC V9
http://www.rfc-editor.org/rfc/rfc3954.txt
The SourceID is not formally defined here, but is defined in the
next document below.
# Cisco V5 and V9
http://www.cisco.com/en/US/docs/ios/solutions_docs/netflow/nfwhite.html
Appendix 1, V9, Table 15, SourceID:
- The Source ID field is a 32-bit value that is used to guarantee
uniqueness for all flows exported from a particular device. (The
Source ID field is the equivalent of the engine type and engine ID
fields found in the NetFlow Version 5 and Version 8 headers). The
format of this field is vendor specific. In Cisco's implementation,
the first two bytes are reserved for future expansion, and will
always be zero. Byte 3 provides uniqueness with respect to the
routing engine on the exporting device. Byte 4 provides uniqueness
with respect to the particular line card or Versatile Interface
Processor on the exporting device. Collector devices should use the
combination of the source IP address plus the Source ID field to
associate an incoming NetFlow export packet with a unique instance
of NetFlow on a particular device.
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
|
Nprobe Bug - Incorrect packet headers in V9 and V10 exports