I analyzed the packet capture, which Nick provided. It turned out, that the
exporter
sends buggy templates for IPv6. Only 1 out of ~30 template refreshes are
correct IPv6,
but the majority are buggy:
buggy templates - contain IPv4 records:
[0] Template ID: 257
template size: 80 buffersize: 80
found extension 0 for type: 21(time sec end), at index: 26, input length: 4
output length: 4 Extension: 0, Offset: 0
found extension 0 for type: 22(time sec create), at index: 27, input length: 4
output length: 4 Extension: 0, Offset: 4
found extension 0 for type: 1(bytes), at index: 1, input length: 4 output
length: 8 Extension: 0, Offset: 8
found extension 0 for type: 2(packets), at index: 3, input length: 4 output
length: 8 Extension: 0, Offset: 12
found extension 4 for type: 10(input SNMP), at index: 13, input length: 2
output length: 2 Extension: 4, Offset: 16
Enable extension: 4: 2 byte input/output interface index
found extension 4 for type: 14(output SNMP), at index: 18, input length: 2
output length: 2 Extension: 4, Offset: 18
found extension 0 for type: 8(V4 src addr), at index: 11, input length: 4
output length: 4 Extension: 0, Offset: 20
found extension 0 for type: 12(V4 dst addr), at index: 16, input length: 4
output length: 4 Extension: 0, Offset: 24
found extension 0 for type: 4(proto), at index: 7, input length: 1 output
length: 1 Extension: 0, Offset: 28
found extension 0 for type: 5(tos), at index: 8, input length: 1 output length:
1 Extension: 0, Offset: 29
found extension 0 for type: 7(src port), at index: 10, input length: 2 output
length: 2 Extension: 0, Offset: 30
found extension 0 for type: 11(dst port), at index: 15, input length: 2 output
length: 2 Extension: 0, Offset: 32
found extension 0 for type: 48(sampler ID), at index: 44, input length: 1
output length: 1 Extension: 0, Offset: 34
Skip unknown element type: 51, Length: 1
found extension 9 for type: 15(V4 next hop IP), at index: 20, input length: 4
output length: 4 Extension: 9, Offset: 36
Enable extension: 9: IPv4 next hop
found extension 8 for type: 13(V4 dst mask), at index: 17, input length: 1
output length: 1 Extension: 8, Offset: 40
Enable extension: 8: dst tos, direction, src/dst mask
found extension 8 for type: 9(V4 src mask), at index: 12, input length: 1
output length: 1 Extension: 8, Offset: 41
found extension 0 for type: 6(flags), at index: 9, input length: 1 output
length: 1 Extension: 0, Offset: 42
correct templates: contain IPv6 records:
[0] Template ID: 257
template size: 40 buffersize: 40
found extension 0 for type: 28(V6 dst addr), at index: 35, input length: 16
output length: 16 Extension: 0, Offset: 0
found extension 0 for type: 4(proto), at index: 7, input length: 1 output
length: 1 Extension: 0, Offset: 16
found extension 0 for type: 7(src port), at index: 10, input length: 2 output
length: 2 Extension: 0, Offset: 17
found extension 0 for type: 11(dst port), at index: 15, input length: 2 output
length: 2 Extension: 0, Offset: 19
found extension 0 for type: 1(bytes), at index: 1, input length: 4 output
length: 8 Extension: 0, Offset: 21
found extension 0 for type: 2(packets), at index: 3, input length: 4 output
length: 8 Extension: 0, Offset: 25
found extension 0 for type: 22(time sec create), at index: 27, input length: 4
output length: 4 Extension: 0, Offset: 29
found extension 0 for type: 21(time sec end), at index: 26, input length: 4
output length: 4 Extension: 0, Offset: 33
found extension 0 for type: 27(V6 src addr), at index: 34, input length: 16
output length: 16 Extension: 0, Offset: 37
The data stream sent by the exporter *always* decodes data according to the
IPv6 template,
but mostly announces IPv4. Therefore most IPv6 flows end up as garbage.
Regards
- Peter
On 31/07/16 12:22, Nikolaos Milas wrote:
> Hello,
>
> I've posted this issue to nfsen-discuss mailing list and as an Issue to
> nfdump GIT issue tracker, but I thought I should post it here as well, since
> it's the most relevant place.
>
> Here is the link to the nfsen-discuss thread:
> https://sourceforge.net/p/nfsen/mailman/nfsen-discuss/?viewmonth=201607
>
> Traffic is exported by a Cisco ISR 2951 Router (using netflow v9) running IOS
> v15.5(1)T2.
>
> IPv6 traffic netflow records are misinterpreted by nfcapd/nfdump v1.6.15
> (tried v1.6.13 too) as IPv4 traffic and are read into the system totally
> wrong.
>
> (Note: IPv6 traffic records from an ASA 5525 is interpreted correctly by the
> same nfsen/nfdump installation.)
>
> IPv4 traffic records are read correctly into nfcapd files.
>
> Here is such a wrong record:
>
> Flow Record:
>
> |Flags = 0x06 FLOW, Unsampled export sysid = 2 size = 60 first =
> 1470300950 [2016-08-04 11:55:50] last = 1470304097 [2016-08-04 12:48:17]
> msec_first = 124 msec_last = 444 src addr = 53.0.0.0 dst addr = 169.0.0.0
> ICMP = 64.8 type.code fwd status =
> 0 tcp flags = 0x11 .A...F proto = 1 ICMP (src)tos = 8 (in)packets = 566
> (in)bytes = 0 input = 4578 output = 54272 |
>
> which was derived by the following packet (exported by Wireshark as plain
> text) referring to IPv6 traffic:
>
> No. Time Source Destination Protocol
> Length Info
> 441 2016-07-31 00:19:59.693603 195.251.204.254 195.251.204.212 CFLOW
> 119 total: 1 (v9) record Obs-Domain-ID= 0 [Data:257]
>
> |Frame 441: 119 bytes on wire (952 bits), 119 bytes captured (952 bits)
> Ethernet II, Src: CiscoInc_52:38:11 (f4:0f:1b:52:38:11), Dst:
> DigitalE_2e:f5:53 (aa:00:00:2e:f5:53) Internet Protocol Version 4, Src:
> 195.251.204.254, Dst: 195.251.204.212
> User Datagram Protocol, Src Port: 57095 (57095), Dst Port: 9995 (9995)
> Cisco NetFlow/IPFIX Version: 9 Count: 1 SysUptime: 146439.410723936 seconds
> Timestamp: Jul 31, 2016 00:19:59.000000000 GTB Daylight Time CurrentSecs:
> 1469913599 FlowSequence:
> 59898 (expected 271165) [Expert Info (Warn/Sequence): Unexpected flow
> sequence for domain ID 0 (expected 271165, got 59898)] SourceId: 0 FlowSet 1
> [id=257] (1 flows) FlowSet Id: (Data) (257) FlowSet Length: 57 [Template
> Frame: 877 (received after
> this frame)] Flow 1 DstAddr: 2001:648:2011:10::236 Protocol: UDP (17)
> SrcPort: 58068 (58068) DstPort: 53 (53) Octets: 169 Packets: 1 [Duration:
> 0.000000000 seconds (switched)] StartTime: 146423.104000000 seconds EndTime:
> 146423.104000000 seconds
> SrcAddr: 2001:648:2011:8002:85c:c793:3e1f:c573 [Expected Sequence Number:
> 271165] [Previous Frame in Sequence: 440] |
>
> I am available to provide whatever additional information/data needed to
> resolve the issue.
>
> *Original packets captured on wire and the respective nfcapd files are
> available at your request.*
>
> Here is the setup on the router that produces the IPv6 netflow export:
>
> |flow record ipv6_record_cisco2 match ipv6 destination address collect ipv6
> protocol collect ipv6 source address collect transport source-port collect
> transport destination-port collect counter bytes collect counter packets
> collect timestamp
> sys-uptime first collect timestamp sys-uptime last ! |
>
> I am using:
>
> |# nfdump -V nfdump: Version: NSEL-NEL1.6.15|
>
> nfdump 1.6.15 was compiled as:
>
> |# ./configure --enable-nsel --enable-nfprofile --enable-nftrack
> --with-rrdpath=/usr/include|
>
> and nfsen:
>
> |# /data/nfsen/bin/nfsen -V /data/nfsen/bin/nfsen: 1.3.6p1 $Id: nfsen 53
> 2012-01-23 16:36:02Z peter $ |
>
> It seems to me that this issue is related to:
>
> https://sourceforge.net/p/nfdump/mailman/message/31901489/
>
> but in this case we do have a source address; however, it seems that the IPv6
> traffic flow records still do not get properly read by nfcapd.
>
> *Please correct nfdump/nfcapd to correctly interpret IPv6 flow records.*
>
> Thanks in advance,
>
> Nick
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Nfdump-discuss mailing list
> Nfdump-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfdump-discuss mailing list
Nfdump-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
