Meraki Netflow 9 template / analysis mismatch

asked 2020-09-29 15:57:25 +0000

dain gravatar image

updated 2020-09-29 15:58:52 +0000

Hi All, I have a capture of netflow data from a meraki mx device that shows a template as follows:

Template (Id = 5206, Count = 13)
Template Id: 5206
Field Count: 13
Field (1/13): IP_SRC_ADDR
    Type: IP_SRC_ADDR (8)
    Length: 4
 ......
Field (5/13): BYTES
    Type: BYTES (1)
    Length: 4
Field (6/13): OUT_BYTES
    Type: OUT_BYTES (23)
    Length: 4
Field (7/13): PKTS
    Type: PKTS (2)
    Length: 4
Field (8/13): OUT_PKTS
    Type: OUT_PKTS (24)
    Length: 4
Field (9/13): PROTOCOL
    Type: PROTOCOL (4)
    Length: 1

Oddly when I look at the following netflow record field 6 shows as postOctet, and field 8 shows as postPacket, the template and netflow record look to be aligned, but this is what I see in the flow itself:

    Flow 2
        SrcAddr: 192.168.100.226
        DstAddr: 172.217.4.46
        SrcPort: 53791
        DstPort: 443
        Octets: 3113
      > Post Octets: 400
        Packets: 5
      > Post Packets: 3
        Protocol: TCP (6)
        InputInt: 33
        OutputInt: 0
        [Duration: 0.228000000 seconds (switched)]
            StartTime: 438933.466000000 seconds
            EndTime: 438933.694000000 seconds

Anyone have any thoughts on the reason for the discrepancy?

thanks /d

edit retag flag offensive close merge delete

Comments

Is it similar to this - Meraki NetFlow Support

Chuckc gravatar imageChuckc ( 2020-09-29 16:19:29 +0000 )edit

It is that exactly. I opened a case so maybe they will admit it's a mess and maybe even fix it.

dain gravatar imagedain ( 2020-09-29 22:02:48 +0000 )edit

Is it the terminology that is the issue or something else?
Version 9 (rfc3954 has type 23 and calls it OUT_BYTES which matches your template.
Wireshark didn't support type 23 until this commit and chose to use the IANA term (sort of) post_octets.
(Looks like this has been discussed a lot over the years - IPFIX changes the names )

Maybe Wireshark should look at the version number (9 vs 10) and use appropriate terms but that seems like a lot of work/coding. Is there a better way to label it?

Chuckc gravatar imageChuckc ( 2020-09-30 00:01:22 +0000 )edit

Not sure, the template looks correct to me, but the flows decode with postXxx instead of outXxx (bytes/packets)

I haven't looked at the code but Elastic Filebeat shows the same issue, which suggests either both wireshark & filebeat are mishandling the templates, or meraki netflow is wonky (and it definetely is in comparing mx64w to mx67 netflows...)

Thanks for the links, nice to see I'm not the only one noticing the issues!

dain gravatar imagedain ( 2020-09-30 00:56:23 +0000 )edit

So I am almost 100% sure the post_xxx vs out_xxx is actually bad netflow decoding. Wireshark gets the neteflow template, and then applies the IPFIX labels to 23/24 netflow fields. The header show 00 09 which afaict is Netflow 9 - ipfix should be 00 0a, I think. FIlebeat seems to do the same thing.

dain gravatar imagedain ( 2020-10-06 02:21:19 +0000 )edit
add a comment