How to Configure Next-Gen Traffic Analytics With NBAR Integration
Click 日本語 for Japanese
Overview
Network-Based Application Recognition (NBAR) is an advanced application recognition engine developed by Cisco. It uses several classification techniques and updates its classification rules easily. NBAR supports 1,500+ applications and sub-classifications, with less than 1% unknown and less than 1% unclassified encrypted traffic. Meraki platforms running the NBAR engine provide granular, enhanced capabilities for client tracking and application enforcement. Refer to the compatibility list for supported applications.
Next-gen NBAR classification improves on the legacy traffic analytics engine in several ways:
- Delivers out-of-the-box visibility into more than 1,500 applications running on a network.
- Enables more granular Layer 7, SD-WAN, and traffic-shaping policies through enhanced application visibility.
- Uses a well-established traffic classification engine already deployed across many Cisco products (on-prem, hybrid, and cloud).
- Provides fine-grained traffic analytics and client tracking.
The legacy engine groups many applications under broad categories such as Miscellaneous secure web and UDP, leaving those flows unclassified.
NBAR-enabled platforms classify these applications instead of grouping them under Miscellaneous secure web and UDP. Administrators can then enforce more granular Layer 7 firewall and traffic-shaping rules, gaining flexibility to block and prioritize specific applications.
SD-AVC integration for cloud-delivered updates
On MX19.1+ firmware with detailed traffic analytics selected, customers opt in to the latest application signatures through a cloud update powered by Cisco SD-AVC cloud services. This process runs seamlessly in the background, without manual intervention or firmware upgrades. This feature currently applies only to MX/Z platforms and will extend to MS and MR platforms in the future.
SD-AVC cloud services also provide cloud feeds that support advanced first-packet classification. This improves the ability of MX/Z devices to classify applications with higher accuracy and efficiency, ensuring quicker and more reliable identification of application traffic. In addition, MX/Z devices contribute select traffic data to SD-AVC cloud services. This data supports intelligence-driven decision-making and aids research and development, driving continuous improvement in application intelligence.
Traffic analytics data gathering occurs from the closest Meraki device to the end node. This design prevents duplication or misrepresentation.
Two examples illustrate this behavior:
-
Scenario 1: Ingress traffic is classified only on the MS355 with regular TA, so users see limited client traffic classification.
-
Scenario 2: Ingress traffic is classified only on the MS390 with NBAR, so users see detailed client traffic classification.
This is by design. Meraki switches shut off sampling on switch ports that receive LLDP packets identifying the neighboring device as another Meraki switch in the same Dashboard network.
Prerequisites
Hardware and software requirements
The following platforms and minimum firmware versions support NBAR:
- Security Appliance (MX/Z): MX16+
- Switching (MS390, default): MS12+
- Wireless (802.11ax / Wi-Fi 6 and newer generations): MR27+
For platform limitations, refer to the Product Firmware Version Restrictions.
Due to hardware limitations, NBAR integration with MR access points is supported only on 802.11ax (Wi-Fi 6) access points. It is not supported on 802.11ac (Wi-Fi 5) Wave 2 and previous generations of MR access points.
How NBAR is enabled per platform
Security Appliance: If the MX network runs MX16+, NBAR is enabled for the firmware and dashboard regardless of the MR or MS networks. This applies when combining or splitting dashboard networks and when upgrading or downgrading firmware. One variable enables NBAR for MX networks:
-
The MX network must run MX16+ firmware.
Wireless: If the MR network runs NBAR, the firmware and dashboard enable it regardless of the MX or MS networks. This applies when combining or splitting networks and when upgrading or downgrading firmware. Two variables enable NBAR for MR networks:
-
All MRs in the MR network must use 802.11ax (Wi-Fi 6) hardware.
-
All MRs in the MR network must run MR27+ firmware.
When the validation checks pass, the dashboard enters a lockdown state. You can no longer add:
-
New non-Wi-Fi 6 APs (requires bypass).
If any validation check fails, NBAR is disabled for the entire MR dashboard network. This keeps traffic analytics uniform across different MR models in the network.
Switching: MS390 is the only platform that supports NBAR. It is enabled by default and cannot be disabled.
Step-by-step instructions
Enable traffic analytics in a combined network
-
Go to Network-wide > Configure > General > Traffic analysis.
-
Set Traffic analysis to Detailed: collect destination hostnames.
The Traffic analysis drop-down offers these options in a combined network:
-
Disabled: do not collect traffic types
-
Traffic analytics is fully disabled.
-
-
Basic: collect generic traffic categories
-
The Network-wide > Monitor > Traffic analytics page is disabled.
-
The Application details page at Network-wide > Monitor > Clients > Application details is enabled.
-
The custom pie chart on the Application details page is enabled.
-
-
Detailed: collect destination hostnames
- The Network-wide > Monitor > Traffic analytics page is enabled.
- The Application details page at Network-wide > Monitor > Clients > Application details is enabled.
- The custom pie chart on the Application details page is enabled.
Enable traffic analytics in a standalone network
-
Go to Network-wide > Configure > General > Traffic analysis.
-
Set Traffic analysis to Traffic analysis enabled.
The Traffic analysis drop-down offers these options in a standalone network:
-
Traffic analysis enabled — The custom pie chart at Network-wide > Monitor > Clients > Application details is enabled. You can configure custom pie charts to further customize the data.
-
Traffic analysis disabled — Traffic analytics is fully disabled.
Configure hostname visibility
Select Report specific hostnames to add the traffic analytics page to your Monitor tab the next time you refresh (Network-wide > Monitor > Traffic analytics). Hostname visibility is a traffic analytics feature. Enabling it lets you view statistics about specific hostnames and IP addresses that clients on your network visit. You can view these statistics for your entire network and per client. This information helps you understand the types of traffic flowing over your network and construct traffic policies that meet your organization's needs. For more information about hostname visibility, refer to our documentation.
Where NBAR applies (supported features)
NBAR classification supports the following configuration areas:
Application tracking:
- Network-wide > Configure > General > Traffic analysis
- Network-wide > Monitor > Clients > Application details
Firewall rules:
- Security & SD-WAN > Configure > Firewall > Layer 7 deny rules
- Wireless > Configure > Firewall and traffic shaping > Layer 7 deny rules
By default, MX processes Layer 3 and Layer 7 firewalls independently. Layer 3 and Layer 7 rules in a group policy behave as one logical firewall, like an MR. For details, refer to the Layer 3 and 7 Firewall Processing Order documentation. To identify which Layer 7 rules block traffic, refer to the documentation that Maps Layer 7 Firewall Rules to NBAR IDs.
When NBAR is enabled and its policies define actions (blocking, traffic shaping, or allowing) for specific traffic flows, these NBAR actions interact with existing firewall rules. In cases of conflict or overlap, the system prioritizes actions in this order: Blocking > Traffic Shaping > Allowing. A block action always takes precedence over traffic shaping or allowing, and traffic shaping takes precedence over allowing.
Traffic-shaping rules:
- Security & SD-WAN > Configure > SD-WAN & traffic shaping > Traffic shaping rules > Enforce L7 traffic shaping policy
- Wireless > Configure > Firewall and traffic shaping > Enforce L7 traffic shaping policy
SD-WAN policies:
-
Security & SD-WAN > Configure > SD-WAN & traffic shaping > SD-WAN policies > Internet traffic
HTTPS Inspection (SSL Inspection) L7 bypass:
-
Security & SD-WAN > Configure > Threat protection > HTTPS Inspection (beta)
Trusted Traffic Exclusions:
-
Security & SD-WAN > Configure > Threat protection > Trusted Traffic Exclusions
Meraki Insight:
- Insight > Monitor > Web App Health > Visibility
- Insight > Monitor > Web App Health > Configure web applications (limited)
Template and group policy support
-
Template support: Templates, and the networks bound to them, use rulesets that are significantly more limited in the classifications NBAR performs. Due to technical limitations, the expanded NBAR rule set is not currently supported. Supported hardware and firmware versions are still required for this functionality.
-
Group policy support: The expanded NBAR rule set follows the NBAR logic for network-wide settings, and applies only to non-template networks. If the network is NBAR-compliant, the configurable rule set supports the expanded list. If it is not compliant, the configurable rule set supports the limited list.
Disable NBAR validation logic to add Wi-Fi 5 or older APs
By default, you cannot add Wi-Fi 5 or older APs to a network that has traffic analysis enabled, contains only Wi-Fi 6 APs (or newer), and runs r27.1+. When you try, the Meraki dashboard displays a banner. This happens because NBAR is automatically enabled for traffic classification under these conditions and cannot be disabled, so the dashboard does not allow you to add Wi-Fi 5 or older APs.
To add Wi-Fi 5 Wave 2 or older APs, temporarily disable traffic analysis:
-
Go to Network-wide > Configure > General > Traffic analysis.
-
Change Traffic analysis to Disabled: do not collect traffic types.
-
Add the Wi-Fi 5 Wave 2 or older AP(s) to the network.
-
Re-enable traffic analysis.
After re-enabling traffic analysis, all the APs in the network, including Wi-Fi 6 APs, use the Legacy Traffic Analytics Engine instead of NBAR. So, the traffic analysis menu may look different.
If you would like use NBAR again, please remove any non-Wi-Fi 6 APs from the network.
Verification
Confirm Layer 7 firewall enforcement in the event log
The Layer 7 firewall rule event type is supported on MX and MR. To verify enforcement:
-
Configure the application (for example, YouTube) among the Layer 7 deny rules.
-
Go to Network-wide > Monitor > Event log.
-
Filter for L7 deny events.
NBAR Blocked events show granular details, including destination port, protocol, destination IP, NBAR ID, classification, and block type.
In one example, DNS queries going out to Google DNS appear, and the MX blocks these requests using NBAR classification.
In another, YouTube makes a direct connection by IP (bypassing the DNS request/response), and the MX also blocks this request. Most applications today include this fallback condition to establish a connection. NBAR classifies both DNS and direct connections, which helps the MX block these flows per the Layer 7 firewall rules.
HTTP Hostname, Port, Remote IP Range (and port), and Geo IP Layer 7 firewall rules currently use Meraki's legacy classification engine rather than NBAR, and do not generate event log entries. To capture these, configure a syslog server.
Troubleshooting
Firmware upgrade and downgrade behavior
When you downgrade from an NBAR-compliant network to a non-NBAR-compliant network for troubleshooting or other purposes, all NBAR IDs are disabled on the firmware and dashboard.
- NBAR configuration is preserved when you upgrade back to an NBAR-compliant network if you do not override any previously configured NBAR rules.
- NBAR configuration is lost when you upgrade back to an NBAR-compliant network if you override the previously configured NBAR rules.
For example, after you remove non-Wi-Fi 6 APs from the network and the network meets the remaining NBAR requirements, Layer 7 firewall and traffic-shaping rules that use NBAR-categorized applications are automatically restored if no changes were made to these rules.
Any changes made to the Layer 7 or traffic-shaping rules while non-Wi-Fi 6 APs were present overwrite the previously configured Layer 7 firewall or traffic-shaping rules that use NBAR.
If an NBAR-compliant network (one that meets the hardware and firmware requirements for NBAR) is brought to a non-compliant state, all configuration that uses NBAR (for example, Layer 7 firewall rules or traffic-shaping rules) is disabled but not lost.
A network becomes non-compliant when you downgrade firmware to a version that does not support NBAR, or when you add an MR access point that does not support NBAR. The Meraki dashboard stores NBAR configuration on the backend while the network is non-compliant.
You retrieve this configuration by returning the network to a compliant state, as long as no changes were made to Layer 7 or traffic-shaping rules while the network was non-compliant. Any changes made to those rules while the network was non-compliant overwrite the previously configured NBAR rules, and all configuration that uses NBAR is lost.