Hello, we have several MXs in our network and some of our users would like to see netflow information in Solarwinds. I configured the Solarwinds with the parameters in Organization>Settings, however it seems it always failed to find the MX. (The solarwinds server is working in a network different where the MXs are). I think the problem is that the Meraki uses an specific set of OIDs and the MIB that is installed in the Solarwinds server doesn´t match them. I downloaded the MIB in the Organization>Settings page, configured the snmp test application with the same parameters and use the MIB to scan it and it returned a lot of information, so the MX is allowing SNMP polls through the cloud. Now, because of the NTA in solarwinds requires the node to be added as SNMP device first, I cannot configure it for netflow. So, what I need to do in solarwinds to make the MX to appear in it as an SNMP node? Thank you very much in advance for your guidance on this.
NetFlow and SNMP are two completely different things. Netflow does not use a MIB.
Meraki sends V9 NetFlow data via UDP.
I found these instructions for configuring SolarWinds for Meraki SNMP if you need to got that way.
Solarwinds is looking for specific required fields in the NetFlow record in order to add it to NTA. I don't know if Meraki has those fields or not. I am ingesting NetFlow from an MX64 into Stealthwatch Cloud and Stealthwatch Enterprise.
Take a look at the link Phillip provided above. I presume that will list the required fields. It looks like the Meraki NetFlow fields are listed here: https://documentation.meraki.com/MX-Z/Monitoring_and_Reporting/NetFlow_Overview
Hi you are correct ! It sends what appears to be standard Netflow V9 data to the collector and I captured it using Wireshark to our Solarwinds netflow collector however the engineer at solarwinds explained that the exporting process periodically resends templates to ensure that the collecting processes have received them. While IPFIX does provide a sequence numbering facility to allow a collecting process ( in this case Solarwinds ) to roughly estimate how many flow records have been lost during export over UDP this does not protect templates. So a collecitng process that loses a template in the middle of the export may be unable to interpret any flow records until the next template re transmission.
Quite a mouthul!
This article explains it all:
Upshot is Solarwinds does not understand the Meraki Netflow data and its only Meraki can fix it by the sounds of it! This is a major issue for some companies that use Netflow extensively on first and second line support desks!
Over to you Mr Meraki.
You know that little "make a wish" button at the bottom right when you're logged into Meraki? I'd press that and put in an enhancement request. It wouldn't hurt to open a case as well with the enhancement request. I would love to see Meraki support flexible NetFlow as well as the ability to have multiple NetFlow destinations, and different flow records.
Full disclosure, I'm a Cisco employee, but don't work in the Meraki Business Unit. When I worked in the Stealthwatch BU, we were always looking for customer input to make our product better. It isn't possible to do everyone's enhancements, but with network visibility being a huge play at Cisco, this one might get attention. Meraki is pretty responsive, but this might be a big request.
If you have a multiple IP address assigned to Meraki, the lowest is the one that Meraki sends out to identify itself.
If you use WAN1 and WAN2, only WAN1 interface reports the flow data correctly.
Ingress data flow never reach Solarwinds. Egress does.
So I am experiencing a similar issue with Solarwinds not receiving Netflow or Syslogging, Through packet captures thou it appears that if you have multiple vlans configured the MX is not using the native vlan as the source. Once i removed all other vlans from the site to site vpn, i started to see netflow traffic and syslog messages. Is there something I can do on the dashboard to correct this behavior so netflow and syslogging are being sourced from the native vlan?
Netflow and syslog use the "Highest VLAN ID".
Let say you have vlan 1 -192.168.1.1 vlan 101 - 10.2.70.4, vlan 999-172.16.150.1
If you can reach all of the vlans from your syslog/netflow server, source IP will be 172.16.150.1
If your syslog/netflow server is at a remote location, and vlan 999 is not reachable, then source IP will be 10.2.70.4
On more than one occasion I've seen it come from a random VLAN number, not the highest or even the lowest number, have seen this for both syslog and netflow and proved on packet captures, have a ticket running on the issue.