Skip to main content
Cisco Meraki

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 that support NBAR provide granular and enhanced capabilities in regards to client tracking and application enforcement.  

NBAR Advantages vs. Traditional Traffic Analytics Engines:

  • 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

  • Fine-grained traffic analytics and client tracking

 

Without NBAR

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 traditional traffic analytics engine.

With NBAR enabled

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

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


Hardware and Software Requirements

Platform support Minimum firmware support
MX  
All MX16+
MS  
MS390 (default) MS12+
MR  
802.11ax (Wi-Fi 6)  MR27+

Please refer to the to 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.

Template Support

NBAR is not supported in templates at this time due to technical limitations. The dashboard network must not be a configuration template or be bound to a configuration template if you wish to use NBAR.

Group Policy Support

NBAR is fully supported in group policy at this time due to technical limitations. 

Note: NBAR integration is ongoing, and Meraki is working to have full integration and support over time.

Stand-Alone vs. Mixed vs. Combined Network Support

What is a stand-alone network?

A stand-alone network is when you have the same specific platform per Meraki dashboard network. For example, your Meraki dashboard network (not Meraki dashboard organization) can only have one of the following:

  • Wireless - Contains the same wireless access points (ex. MR series)
  • Security appliance - Contains a single security appliance or teleworker gateway (ex. MX series); can also contain an HA pair of MX appliances
  • Switch - Contains the same switches (ex. MS series).

What is a mixed network?

A mixed network is when you have the same platform but different models per Meraki dashboard network. For example, your Meraki dashboard network can have only one of the following:

  • Wireless - Contains different wireless access points (ex. MR series)
  • Security appliance - Contains a single security appliance or teleworker gateway (ex. MX series); can also contain an HA pair of MX appliances
  • Switch - Contains different switches (ex. MS series)
NBAR Logic for MR Mixed Networks

There is one main variable which enables NBAR for MR mixed networks (no caveats for MX or MS models):

  • MRs must comply with 802.11ax (Wi-Fi 6) hardware and firmware running MR27+

When the validation is passed, the dashboard gets into a lockdown and thereafter you are unable to add 1) new non-Wi-Fi 6 APs and 2) APs running pre-MR27 firmware. If the 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.

What is a combined network?

A combined network is when you have different platforms and models per Meraki dashboard network. For example, your Meraki dashboard network can have any of the following (including all):

  • Wireless - Contains same/different wireless access points (ex. MR series)
  • Security appliance - Contains a single security appliance or teleworker gateway (ex. MX series); can also contain an HA pair of MX appliances
  • Switch - Contains same/different switches (ex. MS series)

Please refer to our documentation for more information about combined dashboard networks.

NBAR Logic for Combined Networks

There are two main variables which enables NBAR for combined networks:

  • MX must comply with firmware running MX16+
  • MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+

When both validations are passed, the dashboard gets into a lockdown and thereafter you are unable to add 1) new non-Wi-Fi 6 APs and 2) APs running pre-MR27 firmware.

If any validation checks fail, then NBAR is disabled for the entire combined network (except for MS390). This helps keep traffic analytics streamlined in the combined network across different platforms.

Given the different hardware and software requirements per platform and model, let's take a look at the following scenarios in a combined network:

Case#1:

Screen Shot 2020-12-04 at 5.46.00 PM.png

Adding devices to the combined network (sequentially):

      All MX (MX16+) and MS devices

  1. MR36 running MR27+
  2. MR32 running MR26 (unable to add)
  3. MR33 running MR27+ (unable to add)

As shown above, the MR32 and MR33 APs cannot be added due to the new NBAR validation logic for combined networks:

  1. MX must comply with firmware running MX16+: PASS (MX RUNNING MX16+)
  2. MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+: PASS (MR36 RUNNING MR27+ WAS CLAIMED FIRST)

According to the logic statement, "When both validations are passed, the dashboard gets into a lockdown and thereafter you are unable to add 1) new non-Wi-Fi 6 APs and 2) APs running pre-MR27 firmware." Hence, MR32 and MR33 APs cannot be added to this combined network.

When adding MR32 or MR33, you will see a similar dashboard alert:

Screenshot at Aug 03 08-52-50.png  

Refer to our documentation for more information on disabling NBAR.

End device Which Meraki device performs data-gathering for traffic analytics? Traditional TA or NBAR
Device_A MX NBAR
Device_B N/A N/A
Device_C MS450 TA
Device_D MR36 NBAR
Device_E MS390 NBAR
Device_F MS250 TA
Device_G N/A N/A
Case#2:

Screen Shot 2020-12-04 at 4.37.30 PM.png

Adding devices to the combined network (sequentially):

      All MX (pre-MX16) and MS devices

  1. MR36 running MR27+
  2. MR32 running MR26 
  3. MR33 running MR27+ 

As shown above, the MR32 and MR33 APs can be added due to the new NBAR validation logic for combined networks:

  1. MX must comply with firmware running MX16+: FAIL (MX RUNNING PRE-MX16)
  2. MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+: PASS (MR36 RUNNING MR27+ WAS CLAIMED FIRST)

According to the logic statement, "If any validation checks fail, then NBAR is disabled for the entire combined network (except for MS390)." Hence, MR32 and MR33 APs can be added to this combined network.  

End device Which Meraki device performs the data-gathering for traffic analytics? Traditional TA or NBAR
Device_A MX TA
Device_B MR32 TA
Device_C MS450 TA
Device_D MR36 TA
Device_E MS390 NBAR
Device_F MS250 TA
Device_G MR33 TA
Case#3:

Screen Shot 2020-12-04 at 5.21.26 PM.png

 Adding devices to the combined network (sequentially):

      All MX (MX16+) and MS devices

  1. MR36 running MR26
  2. MR32 running MR26
  3. MR33 running MR27+

As shown above, the MR32 and MR33 APs can be added due to the new NBAR validation logic for combined networks:

  1. MX must comply with firmware running MX16+: PASS (MX RUNNING MX16+)
  2. MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+: FAIL (MR36 IS RUNNING MR26)

According to the logic statement, "If any validation checks fail, then NBAR is disabled for the entire combined network (except for MS390)." Hence, MR32 and MR33 APs can be added to this combined network.

End device Which Meraki device performs the data-gathering for traffic analytics? Traditional TA or NBAR
Device_A MX TA
Device_B MR32 TA
Device_C MS450 TA
Device_D MR36 TA
Device_E MS390 NBAR
Device_F MS250 TA
Device_G MR33 TA
Case#4: 

 

Screen Shot 2021-02-15 at 2.14.43 PM.png

Adding devices to the combined network (sequentially):

      All MX (MX16+) and MS devices

  1. MR33 running MR27+
  2. MR32 running MR26 
  3. MR36 running MR27+ 

As shown above, the MR32 and MR36 APs can be added due to the new NBAR validation logic for combined networks:

  1. MX must comply with firmware running MX16+: PASS (MX RUNNING MX16+)
  2. MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+: FAIL (MR33 RUNNING MR27+ WAS CLAIMED FIRST)

According to the logic statement, "If any validation checks fail, then NBAR is disabled for the entire combined network (except for MS390)." Hence, MR32 and MR33 APs can be added to this combined network.

End device Which Meraki device performs the data-gathering for traffic analytics? Traditional TA or NBAR
Device_A MX TA
Device_B MR32 TA
Device_C MS450 TA
Device_D MR36 TA
Device_E MS390 NBAR
Device_F MS250 TA
Device_G MR33 TA
Case#5:

Screen Shot 2021-02-15 at 2.21.18 PM.png

Adding devices to the combined network (sequentially):

      All MX (MX16+) and MS devices

  1. MR36 running MR27+
  2. MR56 running MR27+ 
  3. MR33 running MR27+ (unable to add)

As shown above, the MR33 AP cannot be added due to the new NBAR validation logic for combined networks:

  1. MX must comply with firmware running MX16+: PASS (MX RUNNING MX16+)
  2. MR must comply with 802.11ax (Wi-Fi 6) and firmware running MR27+: PASS (MR36 RUNNING MR27+ WAS CLAIMED FIRST)

According to the logic statement, "When both validations are passed, the dashboard gets into a lockdown and thereafter you are unable to add 1) new non-Wi-Fi 6 APs and 2) APs running pre-MR27 firmware." Hence, MR33 AP cannot be added to this combined network.

When adding MR33, you will see a similar dashboard alert:

Screenshot at Aug 03 08-52-50.png  

Refer to our documentation for more information on disabling NBAR.

End device Which Meraki device performs the data-gathering for traffic analytics? Traditional TA or NBAR
Device_A MX NBAR
Device_B MR56 NBAR
Device_C MS450 TA
Device_D MR36 NBAR
Device_E MS390 NBAR
Device_F MS250 TA
Device_G N/A N/A

Disabling NBAR Validation Logic 

Since all MR access points in a network must be 802.11ax (Wi-Fi 6) in order to support NBAR and ensure that layer 7 and traffic-shaping rules based on NBAR classification are uniformly enforced on all MRs in a network, it's not allowed to add non-Wi-Fi 6 MRs to a network that consists of only Wi-Fi 6 MR with the network firmware set to MR 27.1+. You might run into this corner case if you are adding non-Wi-Fi 6 MR(s) to a network that only has Wi-Fi 6 MR(s) and running MR 27.1 + firmware. When you try to add non-Wi-Fi 6 MR(s) to such network from your Inventory, a banner similar to the following will pop up:

Screenshot at Aug 03 08-52-50.png

Similarly, if you try to move non-Wi-Fi 6 MR(s) to a network that only has Wi-Fi 6 MR(s) and is running MR 27.1 + firmware, the following message will appear:

Screenshot at Aug 24 13-10-53.png

If you still wish to add or move non-Wi-Fi 6 MR(s), please follow the steps below.

Warning: Following the steps below will remove any layer 7 firewall rules and/or traffic-shaping rules that use application(s) categorized by NBAR from the dashboard if such rules are configured. These rules will no longer be enforced.

  1. Temporarily disable traffic analysis from Network-wide > Configure > General page - Traffic analysis section. Change Traffic analysis option to Disabled: do not collect traffic types.
  2. Add non-Wi-Fi 6 MR(s) to the network.
  3. Reenable traffic analysis. Please note that NBAR will stay disabled in this network as long as non-Wi-Fi 6 APs are present.

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

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.

 

 

 

 

  • Was this article helpful?