Next-gen Traffic Analytics - Network-Based Application Recognition (NBAR) Integration
Click 日本語 for Japanese
Overview
Network-Based Application Recognition (NBAR) is an advanced application recognition engine developed by Cisco that utilizes several classification techniques and has the ability to easily update its classification rules. It supports 1,500+ applications and sub-classifications with less than 1% unknown and less than 1% unclassified encrypted traffic. Meraki platforms with the NBAR engine provide granular and enhanced capabilities in regards to client tracking and application enforcement (compatibility list).
Next-gen NBAR Classification vs. Legacy Traffic Analytics Engine:
-
Out-of-the-box visibility into more than 1,500 applications running on a network
-
More granular layer 7, SD-WAN, and traffic-shaping policies using enhanced application visibility
-
Well-established traffic classification engine used by many Cisco products (on-prem, hybrid, and cloud)
-
Fine-grained traffic analytics and client tracking
Legacy Traffic Analytics Engine
As shown above, categories like “Miscellaneous secure web” and “UDP” traffic flows consist of many applications which aren't classified by the legacy traffic analytics engine.
Next-gen NBAR Classification
As shown above, NBAR-enabled platforms will classify more applications as opposed to categorizing as “Miscellaneous secure web” and “UDP” traffic. It also allows administrators to enforce more granular L7 firewall and traffic-shaping rules, giving more flexibility into blocking and prioritizing desired applications.
Prerequisites
Enabling Traffic Analytics
In a combined network, navigate to Network-wide > Configure > General > Traffic analysis and set "Traffic analysis" to "Detailed: collect destination hostnames."
Drop-down options for traffic analysis in a combined network:
Disabled: do not collect traffic types
- Traffic analytics is fully disabled.
Basic: collect generic traffic categories
- Network-wide > Monitor > Traffic analytics page is disabled.
- Application details page found in Network-wide > Monitor > Clients > Application details page is enabled.
- Custom pie chart found in Network-wide > Monitor > Clients > Application details page is enabled.
Detailed: collect destination hostnames
- Network-wide > Monitor > Traffic analytics page is enabled.
- Application details page found in Network-wide > Monitor > Clients > Application details page is enabled
- Custom pie chart found in Network-wide > Monitor > Clients > Application details page is enabled.
In a standalone network, navigate to Network-wide > Configure > General > Traffic analysis and set "Traffic analysis" to "Traffic analysis enabled"
Drop-down options for traffic analysis:
Traffic analysis enabled
- Custom pie chart found in Network-wide > Monitor > Clients > Application details page is enabled.
- Custom pie charts can also be configured to further customize the data based on the above-mentioned parameters.
- Hostname visibility option:
- Selecting "Report specific hostnames" will 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 hostname visibility will allow you to view statistics about specific hostnames and IP addresses that are visited by clients on your network. You can view these statistics for your entire network and per-client. This information can be useful for understanding the types of traffic flowing over your network and constructing traffic policies to meet the needs of your organization. Please refer to our documentation for more information about hostname visibility
Traffic analysis disabled
- Traffic analytics is fully disabled.
Note: The traffic analytics data gathering is performed from the closest Meraki device to the end node. Hence, there's no duplication or misrepresentation.
For more clarity here are 2 examples:
Scenario 1: Ingress traffic will only be classified in MS355 with regular TA. So users will see limited client traffic classification.
Scenario 2: Ingress traffic will only be classified in MS390 with NBAR. Users will see detailed client traffic classification.
This is by design as Meraki switches shut-off sampling on switch ports that receive LLDP packets which identify the neighboring device as another Meraki switch in the same Dashboard network.
Hardware and Software Requirements
| Platform support | Minimum firmware support |
| Security Appliance | |
| MX/Z | MX16+ |
| Switching | |
| MS390 (default) | MS12+ |
| Wireless | |
| 802.11ax (Wi-Fi 6) and newer generations | MR27+ |
For platform limitations, please refer to the Product Firmware Version Restrictions.
Note: Due to hardware limitations, NBAR integration with MR access points is supported only on the 802.11ax (Wi-Fi 6) access points and is not supported on 802.11ac (Wi-Fi 5) Wave 2 and previous generations of MR access points.
Full-stack NBAR Logic
Security Appliance
- If the MX network is running MX16+, then NBAR is enabled for the firmware and dashboard irrespective of MR or MS networks (including when combining/splitting dashboard networks and upgrading/downgrading firmware).
- There is one variable which enables NBAR for MX networks:
- MX network must comply with MX16+ firmware
Wireless
- If the MR network is running NBAR, then enable the firmware and dashboard irrespective of MX or MS networks (including when combining/splitting networks and upgrading/downgrading firmware)
- There are two variables which enables NBAR for MR networks:
- All MRs in the MR network must comply with 802.11ax (Wi-Fi 6) hardware
- All MRs in the MR network must comply with MR27+ firmware
When the validation checks pass, the dashboard gets into a lockdown and thereafter you are unable to add:
- New non-Wi-Fi 6 APs (requires bypass - noted here)
If any validation checks fail, then NBAR is disabled for the entire MR dashboard network. This helps keep traffic analytics uniform in the MR network across different MR models.
Switching
MS390 is the only platform that supports NBAR, and this is enabled by default - cannot be disabled.
Firmware upgrade and downgrade paths
- When downgrading from a NBAR compliant network to a non-NBAR compliant network for troubleshooting or other purposes, all NBAR IDs will be disabled on the firmware and dashboard.
- All configured NBAR information will be stored in the backend when upgrading back to the NBAR compliant network if:
- The user does not override any of the previously configured NBAR rules.
- Respectively, NBAR information will be lost in the backend when upgrading back to the NBAR compliant network if:
- The user does override the previously configured NBAR rules.
- For example, after non-Wi-Fi 6 APs are removed from the network and the network meets the rest of the NBAR requirements, layer 7 firewall and traffic-shaping rules that use application(s) categorized by NBAR will be automatically restored if no changes have been made to these rules. Any changes made to the layer 7 or traffic-shaping rules while non-Wi-Fi 6 APs have been present in the network will overwrite previously configured layer 7 firewall or traffic-shaping rules that use NBAR.
- All configured NBAR information will be stored in the backend when upgrading back to the NBAR compliant network if:
Disabling NBAR Validation Logic
By default, you can't add Wi-Fi 5 or older APs to a network that has traffic analysis enabled, with only Wi-Fi 6 AP (or newer), and running r27.1+. If you try to do add Wi-Fi 5 or older APs to a network under those conditions, the Meraki dashboard displays the following banner:
This is because when the traffic analysis feature is enabled on a network running MR 27.1+ and only contains Wi-Fi 6 APs or newer, NBAR is automatically enabled for traffic classification and can't be disabled. Under these conditions, we are not allowed to add Wi-Fi 5 or older APs to the network.
You will need to disable traffic analysis temporarily in order to be able to add Wi-Fi 5 Wave 2 or older APs. Please follow these steps for instructions:
Warning:
If an NBAR-compliant network (i.e., a network that meets hardware and firmware requirements for NBAR) is brought to an incompliant state, all configuration that uses NBAR (e.g., Layer 7 firewall rules or traffic shaping rules) will be disabled but not lost.
A network can be brought to an incompliant state by downgrading firmware to a version that does not support NBAR or when an MR access point that does not support NBAR is added to the network.
Meraki dashboard will store NBAR configuration on the backend while the network is in an incompliant state. You can retrieve this configuration by bringing the network back to the complaint state and if no changes have been made to L7 or traffic shaping rules while the network was in the incompliant state.
Any changes made to the L7 or traffic-shaping rules while the network was in the incompliant state will overwrite previously configured NBAR rules, and all configuration that uses NBAR will be lost.
-
Navigate to Network-wide > Configure > General page > Traffic analysis. Change the Traffic analysis option to Disabled: do not collect traffic types.
-
Add Wi-Fi 5 Wave 2 or older AP(s) to the network.
-
Re-enable traffic analysis.
Note: 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.
Supportability
Application Tracking
Network-wide > Configure > General page > 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 for MX L3 and L7 firewalls are processed independently. Note that L3 and L7 rules in a group policy behave as one logical firewall just like an MR. For additional details, refer to the Layer 3 and 7 Firewall Processing Order documentation.
For more details on how to identify what Layer 7 rules are blocking traffic, please refer to this documentation that Maps Layer 7 Firewall Rules to NBAR IDs.
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 Support
Templates, and networks bound to them, will have rulesets that are significantly more limited in terms of the classifications performed via NBAR. 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 is supported per the aforementioned NBAR logic for network-wide settings (only applies to non-template networks):
- If NBAR-compliant, then the expanded list will be supported in the configurable rule set
- If not-compliant, then the limited list will be supported in the configurable rule set
Event Log
"Layer 7 firewall rule" event type is supported in MX and MR as shown below:
Youtube is configured among the L7 deny rules
Filter for L7 deny deny events as follows:
As you can see below, NBAR Blocked events showcase granular details on destination port, protocol, destination IP, NBAR ID, classification, block type, ...
In the red box, you can see DNS queries going out to Google DNS and MX is blocking these requests with the help from the NBAR classification.
In the blue box, you can see Youtube is making a direct connection via IP (bypassing the DNS request/response) and MX is also blocking this request. Most applications nowadays have this failback condition to establish a connection. As you can see, NBAR was able to classify both DNS and direct connections, and it helped MX block these flows per L7 firewall rules.
Note: HTTP Hostname, Port, Remote IP Range (and port), and Geo IP L7 firewall rules currently use Meraki's legacy classification engine rather than NBAR, and will not generate event log entries. To capture these, please configure a syslog server.