Purpose
This guide explains how to forward Cisco Meraki logs to Logsign USO via syslog. Meraki MX security appliances, MS switches and MR access points send their event, flow, URL and security logs to an external syslog server that you define in the Meraki Dashboard. Logsign parses these messages whether they arrive directly from the Meraki devices or through a log relay such as Vector.
Prerequisites
- A Meraki Dashboard account with full organization or network administrator rights, which is required to change the network's reporting settings.
- Network connectivity from the Meraki devices (or from your log relay) to the Logsign USO collector on your syslog port (UDP 514 by default).
Step 1: Configure Syslog Forwarding in the Meraki Dashboard
Menu names can differ slightly between Dashboard releases. If a path below does not match your Dashboard, check Cisco's Meraki syslog documentation.
- Log in to the Meraki Dashboard and select the network whose devices you want to monitor.
- Go to Network-wide > General and find the Reporting section.
- Click Add a syslog server, enter the IP address of the Logsign USO collector (or of your relay) and the port.
- Select the roles you want to send, for example Switch event log, Appliance event log, Wireless event log, Flows, URLs and Security events, and save the changes.
Step 2: Add the Data Source in Logsign USO
- Add a new syslog source in Logsign USO.
- Select Cisco as the vendor and Meraki as the product.
- Enter the IP address that the logs arrive from. When the Meraki devices send directly to Logsign, this is the device address. When a relay sits in between, this is the address of the relay (see the next section).
- Save the source.
Receiving Meraki Logs Through a Relay
Some environments collect syslog on an intermediate relay such as Vector and forward it to Logsign from there. A relay of this kind usually places its own RFC 5424 header in front of the original Meraki message, for example:
<14>1 2026-09-18T01:05:25.000000Z 10.0.0.2 vector - - - 1789718752.200511634 SW_ACC_1 events port 29 status changed from down to 1Gfdx
Logsign finds the Meraki part of the line (the timestamp, the device name and the log type) wherever it starts, so both this relayed form and the native Meraki form are parsed the same way. The relay must leave the Meraki message itself unchanged.
Logsign matches incoming syslog to a source by the address of the sender, so every device behind a relay arrives on the source defined for the relay's IP address. If the relay also forwards logs from other devices, such as Cisco IOS routers or Catalyst switches, add their parsers to the same source with Parser Fallback:
- Open the relay's syslog source and keep Cisco / Meraki as its main vendor and product.
- Under Parser Fallback, click Add, select the vendor and product of the other device type (for example Cisco / Router or Cisco / Switch) and save. Repeat for each device type.
- Arrange the entries in the Parser Fallback List by dragging them into the order you want, then save the source.
Each line is tried with the main parser first and then with the fallback parsers in list order, and the first parser that recognizes the line is used. The Meraki parser only accepts lines that carry a Meraki log type, so it does not take over IOS messages from the other devices.
Supported Log Types
| Meraki log type | Content |
|---|---|
events |
Event log of MS switches, MX appliances and MR access points, including DHCP, switch port and spanning tree events |
flows, ip_flow_* |
Traffic flows with source, destination, protocol and ports |
urls |
HTTP requests with client address, URL, method and user agent |
firewall, vpn_firewall |
Firewall and site to site VPN firewall rule hits |
ids-alerts, security_event |
Intrusion detection and security events, including the signature and priority |
The Meraki timestamp at the start of the message can be a Unix time or, on a device that has just started and has not yet synchronized its clock, the device uptime (for example 86.490117775). Both forms are accepted.
MS Switch Events
The following switch events are recognized and classified. Other lines of the switch event log are still parsed, and their key=value parts are extracted into fields.
| Meraki message | Event.Action | EventMap (Context / Type / SubType) |
|---|---|---|
port 29 status changed from down to 1Gfdx |
port_up |
Network / Interface / Up |
port 12 status changed from 1Gfdx to down |
port_down |
Network / Interface / Down |
Port 5 changed STP role from disabled to designated |
stp_role_change |
Network / Other / Info |
Switch A8:46:9D:EB:6A:69 is no longer the root bridge |
root_bridge_change |
Network / Other / Info |
type=mac_flap_detected mac='66:85:43:6A:31:0D' vlan='140' port='40,39,40' |
mac_flap_detected |
Network / Other / Error |
A port change counts as a link up whenever the new status is anything other than down, for example a speed and duplex value such as 1Gfdx. STP role changes are recognized for regular ports, aggregate ports such as AGGR/0 and stack ports such as A8:46:9D:EB:6A:69/1.
What Gets Collected for Switch Events
| Logsign Field | Content |
|---|---|
| EventSource.HostName | Name of the Meraki device from the message, for example SW_ACC_1 |
| Event.Prefix | Meraki log type (events) |
| Event.Action | Event name from the table above |
| Event.Info | Short description, for example Switch port link up or MAC address flapping detected |
| Switch.Port | Port the event refers to. For MAC flapping, the list of ports the address moved between. |
| Event.PreviousValue | Previous port status or previous STP role |
| Event.NewValue | New port status or new STP role. For root bridge events, now or no longer. |
| Device.MAC | MAC address of the switch in root bridge events, or of the flapping address in MAC flap events |
Every Meraki event is recorded with Vendor Cisco, Product Meraki, EventSource Type Network System and Category Wireless LAN Controller. The category is the same for MS switch and MX appliance events, so filter on EventSource.HostName or Event.Prefix when you need to separate device types in searches and reports.
Notes and Limits
- Time.Generated is the time Logsign processed the message. The Meraki timestamp inside the message is not used for this field.
- The severity of each event comes from the priority value of the syslog header. Some relays replace the original priority with a fixed value (Vector commonly sends
<14>, user.info). In that case every event is recorded as informational. Configure the relay to keep the original priority if you rely on severity in alerts or reports. - Event log lines that Logsign does not have a classification for, such as switch events not listed in the MS Switch Events table, are parsed but stored without an EventMap.
- Each Meraki message must arrive as a single syslog message on a single line. If the relay merges or splits messages, the affected lines are shown as uncategorized.