Are you looking for Meraki NetFlow Support? We recently came across this flow export and ran it through our lab. We found some interesting information and wanted to share it with other Meraki customers who may run into issues when trying to look at the data with their IPFIX or NetFlow Analyzer. We have not been able to get someone at Meraki to comment yet.
When we viewed the replayed Meraki NetFlow packet capture in our IPFIX and NetFlow reporting system everything appeared to be fine. Then, we dug in to take a closer look.
When we ran the “Flow View” report, we saw two elements (postOctetDeltaCount and postPacketDeltaCounts) that grabbed our attention:
Normally we only see these values in devices that are modifying packets before forwarding them (e.g. compression).
Some of us were thinking that these were bi-flows but, for that to be true, they would have needed to implement something like RFC 5103 which states that:
Reverse Information Elements are specified as a separate “dimension”
in the Information Element space, assigning Private Enterprise Number
(PEN) 29305 to this document, and defining that PEN to signify “IPFIX
Reverse Information Element” (the Reverse PEN). This Reverse PEN
serves as a “reverse direction flag” in the Template; each
Information Element number within this PEN space is assigned to the
reverse counterpart of the corresponding IANA-assigned public
Information Element number. In other words, to generate a Reverse
Information Element in a Template corresponding to a given forward
Information Element, simply set the enterprise bit and define the
Information Element within the Reverse PEN space
If ‘post’ counters is what the software developers at Meraki intended (i.e. not bi-flows), why are there no return flows? I In other words, we observed flows representing traffic from host ‘A’ to host ‘B’ but, not from B back to A.
NOTE: We cannot rule out yet that the customer may have miss-configured the device, but the configuration looked fine to us. Based on the interface to configure NetFlow, it seems a bit limited in areas to make a mistake (below).
When we see traffic from host ‘A’ to host ‘B’ and don’t see a return flow from B back to A, we expect to see biflows and the Reverse Information Elements <above> apply but, we didn’t see them in the export. Because we didn’t see a return flow, we suspected that these were actually biflows.
OctetDeltaCount and postOctetDeltaCount are counters which represent how much data was in the flow as it came into the Meraki device and how much data was in the same flow just before it left the device. This could very well be what Meraki intended however, we have never seen this before. As a result of not seeing return flows, we speculated that the post counters were given the wrong element IDs. But, speculation can lead to false assumptions and we want to confirm that the export is as intended by Meraki.
The Meraki documentation outlines what is exported in the flow template as shown below:
Notice above that it lists OUT_BYTES and OUT_PKTS as listed in RFC 3954 . However, in the image below, Post values appear which is technically accurate.
The ‘out’ value was later named to ‘post’ and intended to imply the same thing. We verified this in our lab after receiving a packet capture from a customer.
Although there is nothing wrong technically with what is being exported or even with how it is exported, we still found it a bit bizarre that no return flows were found. In other words, we get details on how the flow from ‘A’ looked as entered the Meraki device, a second counter just before it exits the Meraki device but, nothing on the return flows from ‘B’ back to ‘A’. Below is a diagram showing what we understand about the export.
NOTE: The Meraki documentation states that “The MX and Z1 do not support exporting an SNMP ingress or egress interface index via NetFlow.” This means that some NetFlow Analyzers will not be able to report on the export. Ours worked fine as shown at the very top of this post. The Observation Point is also absent from the Meraki export but, it isn’t needed for post values HOWEVER, it is absolutely necessary should Meraki decide to export egress flows sometime in the future.
Contact our team if you have questions on any of this.