Cisco Meraki: send syslog and NetFlow to MobiObs

Before you start

The MobiObs device is 10.20.4.9 in the examples; use the address on its Network screen. Android does not let apps listen on ports below 1024, and MobiObs uses the same ports on every platform, so use these destinations:

You need Dashboard access with write permission on the network. Put the MobiObs device where the Meraki devices can reach it: a LAN VLAN behind the MX, or a staff SSID without client isolation. The MX chooses the source address for syslog by routing: normally the LAN interface of the VLAN that leads to the server. If the server is reached over site-to-site VPN and no VLAN takes part in the VPN, Meraki documents a 6.x.x.x source address instead, which you may need to allow in VPN firewall rules.

Syslog servers

1. In Dashboard, select the network and go to Network-wide > Configure > General.
2. Find Syslog servers under Reporting. In a network with only one device type (only appliances, only switches or only wireless), it is under Logging instead.
3. Click Add a syslog server. Enter 10.20.4.9 as the server and 5514 as the port.
4. Choose the roles to send, then save the page.

Roles decide which messages go to the server, and they depend on the product:

Dashboard labels the roles per product, for example Appliance event log or Wireless event log, and since March 2026 shows separate appliance and wireless versions of the URLs and flows roles. For a site visit, start with the event logs and security events. The flows and URLs roles send one message per connection or web request, which is useful but busy on a large network.

Meraki syslog is UDP by default. TCP syslog needs MX 26.1 or MR 33.1 firmware or later; with it, you can use tcp/5514, which does not drop messages in bursts. MobiObs detects the message format automatically, so there is no format setting to match.

NetFlow on the MX

1. Go to Network-wide > Configure > General and find NetFlow traffic reporting under Reporting.
2. Set it to enabled, enter 10.20.4.9 as the NetFlow collector IP and 2055 as the NetFlow collector port.
3. Save the page.

The MX exports NetFlow version 9, which MobiObs decodes on udp/2055. Two limits from Meraki’s documentation matter on site:

• One collector per network. If the network already exports to a permanent collector, replacing it with MobiObs stops that export until you put the original address back. Note the existing values first.
• Routed traffic only. The MX exports flows for traffic it routes or translates. Traffic switched within one VLAN never reaches the MX and does not appear. For a branch uplink, that is exactly the traffic you want; see top talkers on a branch uplink.

Some MS switch models can also export NetFlow; Meraki documents those separately.

SNMP traps

Meraki SNMP traps are configured under Network-wide > Configure > Alerts, but Meraki documents that traps are always sent from the Meraki cloud, not from the devices on site, and that the receiving server must have a public IP address. A MobiObs device on a private LAN address cannot receive them without a public address and a port forward, which is rarely appropriate for a temporary capture.

Use the event log syslog roles instead. They report the same kinds of events that alerts and traps cover, such as ports going up and down, VPN changes and client association failures, and they arrive from the device directly.

Verify it works

• Logs. Event log messages from the MX, MR or MS should appear within a minute or so of saving, tagged with the device as host. Filter Logs by that host to see one device. To create an event on demand, change something harmless such as a port description, or reconnect a test client to an SSID.
• Flows. Within a few minutes of enabling NetFlow, Flows shows bytes over time and the top talkers through the MX. The first flows appear once the MX has sent its template.
• Sources. Lists each Meraki device that has reached the MobiObs device, with the kinds of data it sent and when it was last seen.

If nothing arrives, the Dashboard Ping live tool on the MX tests whether it can reach 10.20.4.9, and a Dashboard packet capture on the LAN interface shows whether UDP to port 5514 or 2055 is leaving.

Troubleshooting

• The port is still 514. Check that the port field says 5514; MobiObs listens on 5514 on every platform, and Android apps cannot listen on 514.
• No messages from access points. The MR sends syslog from its own address on the management VLAN. Check that the management VLAN can route to the MobiObs device, and that a guest SSID with client isolation is not in the path.
• Messages stop over VPN. When the MobiObs device is at another site, check the source address rules above and the site-to-site VPN firewall.
• Flows are empty but syslog works. Check the collector port is 2055, then generate routed traffic, for example from a client to the internet. Same-VLAN traffic is not exported.
• Large gaps in the flows or URLs roles. UDP is dropped under load before it reaches any collector. Reduce the roles you send, or use TCP where the firmware supports it.

Remove it afterwards

On Network-wide > Configure > General, delete the MobiObs syslog server, and either disable NetFlow traffic reporting or restore the original collector IP and port. Save the page. If you replaced an existing NetFlow collector, check that it is receiving again.