Guest

Network Based Application Recognition (NBAR)

NBAR2 or Next Generation NBAR

Hierarchical Navigation

Downloads

Last updated: January 2012

Common questions and answers regarding Cisco® NBAR2 or Next Generation Network-Based Application Recognition (NBAR).

Q. What is NBAR2?
A. NBAR2 (or Next Generation NBAR) is a re-architecture of NBAR based on the Service Control Engine (SCE) with advanced classification techniques, accuracy and many more signatures. NBAR2 is backward compatible and is supported on ISR-G2 and ASR1K platforms. NBAR2 is adopted as a Cisco cross platform protocol classification mechanism. It supports 1000 + applications and sub-classifications, and Cisco adds 100+ new signatures per year to the protocol pack.
Q. What are the key benefits of NBAR2?
A. NABR2 offers following key benefits over NBAR:

• Advanced Classification Techniques: The NBAR2 leverage classification technique from SCE (Multi-Packet Engine), which allows classification of IPv4, IPv6 and v6 transition techniques. It offers classification per categories, sub-categories and attributes.

• Common Protocol Library for NBAR2 Across Platforms: NBAR2 offers platform independent signatures. It combines protocol libraries developed for NBAR and SCE appliances, giving more signatures to customers.

• Signatures Delivery Through Protocol Pack: A protocol pack is a set of protocols developed and packaged together. Protocol packs are a means to distribute protocol updates outside the IOS release train, and can be loaded on the router without replacing the IOS or reloading the device.

• Support for Up to 121 Custom Protocols.

Q. What is attribute based classification offered by NBAR2?
A. NBAR uses "match protocol [application-1]" to classify interested applications. If a user wants to classify all emails such as outlook, gmail, hotmail, yahoo-mail, etc., then one has to add match the protocol statement for each email type.

NBAR2 groups applications based on attributes such as category, sub-category, and application-group, p2p, tunnel and encrypted. Category email classifies all emails such as outlook, gmail, hotmail, yahoo-mail, etc. User can configure a single match statement to classify all emails:

"match protocol attribute category email"

Q. How is traffic categorization done in NBAR2?
A. NBAR2 groups applications based on various attributes such as:

• Application-group: Grouping of applications that are part of the same application suite or "brand" - e.g.: Yahoo-Messenger, Yahoo-VoIP-messenger, and Yahoo-VoIP-over-SIP are grouped together under `yahoo-messenger-group'

• Category: Grouping of applications which support similar functionality from an end-user standpoint. E.g.: `email', `gaming', `newsgroup' etc.

• Sub-category: Similar to category, providing a secondary grouping of applications with similar functionality from an infrastructure/networking standpoint. E.g.:' routing-protocol', `database', `streaming' etc.

• P2P (Peer-to-Peer)-Technology: Boolean attribute indicating if this application uses a p2p technology

• Tunnel: Boolean attribute indicating if an application tunnels other protocols

• Encrypted: Boolean attribute indicating if an application is encrypted

Please visit the protocol library at this link to see how applications are categorized.
Q. How does NBAR2 report application information?
A.

• NBAR Protocol Discovery MIB: This is supported on all platforms that support the NBAR protocol discovery. It provides per interface, per protocol and bi-directional statistics (bit rate (bps), packet counts and byte counts). It Includes statistics for traffic identified with user-defined custom application classifications. A user can configure and view multiple top-n tables listing protocols by bandwidth usage. If a protocol discovery is enabled via the MIB, it will be enabled for both IPv4 and IPv6.

• Cisco Class Based QoS-MIB: This provides statistics per class (not per application, unless we have one application per class). It provides statistics for traffic before and after QoS policy is applied.

• Flexible NetFlow (FNF): NBAR application name inclusion in Flexible NetFlow record creates an association of application name with flow reporting.

Q. Which platforms support NBAR2?
A. NBAR2 is only supported on ISR-G2 and ASR1000
Q. Which protocols can NBAR2 classify?
A. NBAR2 can classify the following applications and protocols from Layer 4-7.

• Statically Assigned TCP and UDP Port Numbers.

• Non-TCP and non-UDP IP Protocols.

• Dynamically Assigned TCP and UDP Port Numbers. This kind of classification requires stateful inspection; the ability to inspect a protocol across multiple packets during packet classification.

• Subport Classification or Classification Based on Deep-Packet Inspection.

Deep-packet classification is performed at a finer level of granularity. For instance, if a packet is already classified as HTTP traffic, it may be further classified by HTTP traffic with a specific URL.

Q. Will NBAR2 be able to support new and emerging applications?
A. Cisco provides NBAR modules (also known as PDLM files) to add support for new and requested applications. A PDLM extends the list of protocols that NBAR can recognize. The PDLM can usually be loaded without changing the Cisco IOS Software image and without a reload. A PDLM is a separate file available on Cisco.com and can be loaded from flash memory.

Additional protocols supported via PDLMs are included in later subsequent IOS images.

Cisco NBAR2 supports a protocol pack model, in which an upgrade to a higher version protocol pack can add support to new and requested applications without changing the Cisco IOS Software image and without a reload.

Q. How do I configure NBAR2?
A. NBAR2 configuration is the same as NBAR. It is a two mode operation: a] Protocol Discovery; b] Modular QoS traffic classification.

Configure protocol discovery to discover and get real time statistics of applications currently running in your network. Use these statistics from the protocol discovery mode, to define QoS classes and policies using modular QoS traffic classification configuration.

One can use FNF (Flexible NetFlow) instead of protocol discovery to discover and get real time statistics of applications running in your network.

Q. How do I configure protocol discovery and what information does it provide?
A. Protocol discovery configuration is same as NBAR. The protocol discovery feature provides real time statistics on applications currently running on the network. It provides per interface, per protocol and bi-directional statistics (bit rate (bps), packet counts and byte counts).

This helps you define QoS classes and polices, such as how much bandwidth to provide to mission-critical applications, and how to determine which protocols should be policed.

The command to configure Protocol Discovery:

Router(config)# interface fastethernet 0/0

Router(config-if)# ip nbar protocol-discovery

Q. How do I configure modular QoS traffic classification?
A. Modular QoS configuration for NBAR2 is same as NBAR. It is a simple three step configuration:
a] Use a class-map command to identify traffic:

Router(config)# class-map [match-all | match-any]class-name

Router(config-cmap)# match protocol attribute category email

NBAR2 allows attribute based traffic classification.
b] Use a policy-map command to define how to treat the traffic:

Router(config)# policy-map policy-name

Router(config-pmap)# class class-name

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

The services which can be configured using policy-map are:

• Guaranteeing bandwidth with Class-Based Weighted Fair Queuing (CBWFQ)

• Policing and limiting bandwidth

• Marking for differentiated service downstream or from the service provider (ToS or Diff Serv code points [DSCP])

• Drop policy to avoid congestion (Weighted Random Early Detection [WRED])

c] Use a service-policy command to apply this policy on the interface:

Router(config)# Interface Serial1

Router(config-if)# service-policy [input | output] policy-map-name

Q. How do I manage NBAR2 with an application other than the CLI?
A. CiscoWorks QoS Policy Manager (QPM) is able to manage NBAR. CiscoWorks QPM facilitates centralized management of Quality of Service (QoS). It provides comprehensive QoS provisioning and monitoring capabilities for successful deployment and optimal utilization of network resources. QPM supports real-time and historical Cisco NBAR protocol discovery monitoring for traffic baselining, to separately monitor the application traffic inbound and outbound from device interfaces. Analysis includes displaying traffic statistics (including NBAR filters) before and after QoS policy deployment and charting QoS action statistics.
Q. Is a MIB available to monitor NBAR2?
A. Yes. The CISCO-NBAR-PROTOCOL-DISCOVERY MIB is available for monitoring NBAR. This MIB provides statistics (bit rate (bps), packet counts, and byte counts) per direction, per application recognized by NBAR. It Includes statistics for traffic identified with user-defined custom application classification.

This MIB is supported on all platforms that support the NBAR protocol discovery.

Q. What is a protocol pack?
A. A protocol pack is a set of protocols developed and packaged together. Protocol packs are a means to distribute protocol updates outside the IOS release train, and can be loaded on the router without replacing the IOS . Right now, new protocol packs are linked to new IOS images. However, we can build a new one to correct a bug or support new applications. At any point, there's only a single "active" protocol pack in the device. A newly loaded protocol pack replaces the current protocol-pack. A device IOS image has an in-built default protocol pack. If the active protocol-pack is unloaded, image will return to the in-built default protocol pack. Custom protocols and PDLMs are retained. Protocol Pack load/unload causes the current classification state and stats to reset.
Q. How to load/unload protocol pack:
A. The command to load a protocol pack:

Config# ip nbar protocol-pack <protocol pack file> [force]

For example:

ip nbar protocol-pack harddisk:protocolPackFile

To unload any previously loaded protocol pack, "no" version of the above CLI should be executed.

For example:

no ip nbar protocol-pack harddisk:protocolPackFile [force]

Another way to revert to the default protocol pack is:

ip nbar protocol-pack harddisk:protocolPackFile

Q. What is the use of the "force" option while loading/unloading a protocol pack?
A. The CLI should be executed with the "force" argument in the following scenarios:
1. When the user needs to retain the loaded protocol pack configuration across the IOS version upgrades/downgrades
2. The force option can be used to override the active protocols check. When the force option is used, the CLI will be accepted if the protocol pack doesn't contain the current active protocol(s)
Q. How do I check the protocol pack on the device?
A. To display information on the loaded (active) protocol pack or a protocol pack file that resides on the router, the following command should be executed:

Router# show ip nbar protocol-pack <active | protocol pack file> [detail]

Without the "detail" argument, the protocol pack information such as name, publisher, and version will be displayed.

With the "detail" argument, the content of the protocol pack such as the protocols and version in the pack will be displayed.

Q. Why is NBAR2 transitioning to the protocol pack model?
A. The application recognition module (also known as PDLM) is used to add support for a protocol that is currently not available as part of Cisco IOS Software. A PDLM extends the list of protocols that NBAR can recognize.

A protocol pack is a single compressed file that contains multiple PDL files and a manifest file. Your organization determines the contents of the protocol pack. Protocol packs allow you to load a set of protocols together, rather than load them separately.

Protocol packs are easy to load. They are easy to upgrade to a higher version protocol pack or revert to a lower version protocol. A protocol pack can be loaded on the router without replacing the IOS image or without rebooting the device.

Q. What support does NBAR2 have for IPV6 traffic?
A. NBAR2 supports IPV6 traffic classification, filtering and reporting.
1. Classification of IPV6 traffic

• Classification of applications natively over IPv6

• Classification of applications using v6 over v4 transition mechanisms

– Teredo

– IP protocol-type 41

– Classifies applications inside tunnels that transit the router

2. Protocol discovery statistics can be configured on an interface for IPv4 only, IPv6 only or both

• When both are enabled, aggregate statistics are shown per application

• v6 over v4 traffic shows up as IPv4 stats

3. Modular QoS policies apply to both v4 and v6 traffic
4. Flexible NetFlow flow monitors can be applied for both v4 and v6 traffic

• v6 over v4 traffic is reported as v4

Q. How do I configure NBAR2 to classify IPV6 traffic?
A. Classify the traffic inside the tunnel:

Router (config)# ip nbar classification tunneled-traffic ipv6inip | teredo

Option "ipv6inip" classifies applications in IPv6 traffic encapsulated within the IPv4 protocol type 41 payloads.
Option "teredo" classifies applications in the IPv6 traffic encapsulated within the teredo tunnels.

• Configuration will apply to IPv4 traffic seen on the interfaces, where NBAR is enabled.

Q. What does NBAR2 not support?
A. NABR2 does not support following traffic:

Non-IP traffic

MPLS labeled packets

Asymmetric flows (the flows in which different packets of the flow go through different routers) with stateful protocols.

• If both directions of a flow do not pass through the same device, stateful classification will fail

• Limited support for a few protocols (e.g. HTTP)

ASR1000 only

• Packets that originate from or that are destined to the router running NBAR

• Multicast packets

Encrypted/tunneled traffic

• IPSec transit traffic classified as IPSec

• De-tunneling supported for limited tunnel types (v6 in v4) in the case of transit tunnels

• Note: multi-packet heuristics used for SSL/TLS traffic in several cases, has been supported with high success. Examples: skype, gtalk

IP Fragmentation

• Classification attempted on only the first fragment

• Multi-packet classification is affected

Out of order packets may not be classified properly.
Q. Does NBAR2 have any limitations on the ASR1000?
A. The following are the current limitations on ASR1000 platforms:
Unsupported Interfaces:

• Dialer interfaces

• Dynamic tunnels such as Dynamic Virtual Tunnel Interface (DVTI)

• Fast Ether channels

• IPv6 tunnels that terminate on the router

• Multilink interfaces such as Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MLFR)

• MPLS

• Overlay Transport Virtualization (OTV) overlay interfaces

• Port channels

• VRF-Aware Service Infrastructure (VASI)

• GETVPN IPSec tunnels

Protocol Discovery on up to 32 interfaces
By design, NBAR processing is temporarily disabled during the In-Service Software Upgrade (ISSU)
(Note: You cannot use NBAR to classify output traffic on a WAN link where tunneling or encryption is used. Therefore, you should configure NBAR on the other interfaces of the router (such as a LAN link) to perform input classification before the traffic is switched to the WAN link.)
Q. Does NBAR2 have any limitations on ISR G2 platforms?
A. The following are the current limitations on ISR G2 platforms:

Interfaces need to have CEF enabled

• Fast EtherChannel interfaces are not supported

Tunnel interface support

• Simultaneous NBAR configuration on both main and tunnel interfaces are un-supported, except for IPSec tunnels

• IPSec GETVPN tunnels are un-supported

Q. What impacts NBAR2 performance?
A. Several factors can impact NBAR2 performance in software-based execution:
A. Router configuration
1. Number of protocols being matched against it
2. Number of regular expressions being used
3. The complexity of packet inspection logic required
4. NBAR2 features that are enabled also impact performance. Sub-port classification, and in future field-extraction.
b. Traffic profile (packet protocol sequence)
1. The number of flows
2. Long duration flows are less expensive than shorter duration flows
3. Stateful protocol matches are more performance impacting than static port applications. A traffic mix consisting of a high volume of short-lived flows requires a higher level of resources to classify new flows which soon "expire" from the flow cache. Conversely, a lower level of resources is required with a traffic mix of fewer and longer-lived flows, since these flow entries would be in the cache for a longer amount of time.
4. Packet size
Things that do not Impact NBAR2 performance:
1. Post match actions (such as queuing, tagging, etc.)
2. Link speed (NBAR is interface agnostic)
3. Having NBAR2 on multiple interfaces (packets already classified are cached, no reclassification will take place)
4. Inbound vs. outbound packet matches (using NBAR2 on service policy input instead of service policy output)