Skip to main content
Cisco Meraki

Next-gen Traffic Analytics - Network-Based Application Recognition (NBAR) Integration

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

Screen Shot 2020-11-25 at 2.37.56 PM.png

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

2.png

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.

3.png

Enabling Traffic Analytics

In a combined network, navigate to Network-wide > Configure > General > Traffic analysis and set "Traffic analysis" to "Detailed: collect destination hostnames." 

Screen Shot 2020-11-30 at 2.07.25 PM.png

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.Screen Shot 2021-06-25 at 4.16.22 PM.png
  • 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.Screen Shot 2021-06-25 at 4.15.02 PM.png
  • 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" 

Screen Shot 2021-06-25 at 3.57.58 PM.png

Drop-down options for traffic analysis:

Traffic analysis enabled

  • Custom pie chart found in Network-wide > Monitor > Clients > Application details page is enabled.Screen Shot 2021-06-25 at 4.07.33 PM.png
    • Custom pie charts can also be configured to further customize the data based on the above-mentioned parameters.
  • Hostname visibility option:
    • Screen Shot 2019-08-23 at 9.55.18 AM.png
      • 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 of 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
      • Screen Shot 2021-06-25 at 4.23.44 PM.png

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:

Ms390 (1).svg

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: 
  1. 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:
  1. All MRs in the MR network must comply with 802.11ax (Wi-Fi 6) hardware
  2. 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:

  1. 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.

 

Disabling NBAR Validation Logic 

As we mentioned previously, all access points in a network must be Wi-Fi 6 or newer, and the network firmware version must be set to MR 27.1 or more recent to support NBAR. 

Therefore, it's not allowed to add Wi-Fi 5 Wave 2 or older APs to a network that consists of only Wi-Fi 6 or newer APs with the network firmware set to MR 27.1+. If you try adding Wi-Fi 5 Wave 2 or older APs to a network that matches the above requirements, you might run into this corner case. Meraki dashboard will display the following banner:

Screenshot at Aug 24 13-10-53.png

Please follow the steps below if you still wish to add Wi-Fi 5 Wave 2 or older:

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.

  1. Temporarily disable traffic analysis from Network-wide > Configure > General page - Traffic analysis section. Change the “Traffic analysis” option to Disabled: do not collect traffic types.

  2. Add  Wi-Fi 5 Wave 2 or older AP(s) to the network.

  3. Re-enable traffic analysis. Please note that NBAR will stay disabled in this network as long as Wi-Fi 5 Wave 2 or older AP(s) are present.

If you would like to re-enable NBAR in this network, please remove any non-Wi-Fi 6 APs from the network.

Supportability

Note: Meraki is actively working on full-stack NBAR template integration.

Application Tracking 

Network-wide > Traffic analytics
Network-wide > Clients > Application details 

Screen Shot 2021-09-22 at 3.46.19 PM.png

Firewall rules 

Security & SD-WAN > Firewall > Enforce Layer 7 deny rules
Wireless > Firewall and traffic shaping > Enforce Layer 7 deny rules 

3.png

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 > SD-WAN & traffic shaping > Traffic shaping rules > Enforce L7 traffic shaping policy
Wireless > Firewall and traffic shaping > Enforce L7 traffic shaping policy 

Screen Shot 2021-09-22 at 3.50.18 PM.png

HTTPS Inspection (SSL Inspection) L7 bypass

Security & SD-WAN > Threat protection > HTTPS Inspection (beta)

Screen Shot 2021-09-22 at 3.55.26 PM.png

Meraki Insight

Insight > Web App Health > Visibility
Insight > Web App Health > Configure web applications (limited)

Screen Shot 2021-09-22 at 3.56.45 PM.png

Template Support

The expanded NBAR rule set is not supported in templates at this time due to technical limitations. While classifications will still be performed via NBAR if the device in question supports it, and is running firmware that supports it, the configurable rule set will be significantly more limited in templates, and networks bound to a template.

Group Policy Support

The expanded NBAR rule set is not supported in Group Policies at this time due to technical limitations. While classifications will still be performed via NBAR if the device in question supports it, and is running firmware that supports it, the configurable rule set will be significantly more limited in Group Policies.

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

Screen Shot 2022-04-08 at 4.20.37 PM.png

Filter for L7 deny deny events as follows: 

Screen Shot 2022-04-08 at 3.59.15 PM.png

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.

Screen Shot 2022-04-08 at 4.18.08 PM.png

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.