Hands-On Lab: Configuring NBAR2 for Application Visibility

Lab Objective

Enable NBAR2 protocol discovery on an interface, review the resulting application breakdown of observed traffic, then configure a class-map matching a specific application by NBAR2 signature rather than port number, and apply QoS treatment based on that classification.

Lab Purpose

Every class-map covered throughout the QoS labs in this series matched traffic using ACLs, DSCP values, or simple protocol/port matches — none of which reliably identify an application that uses dynamic ports or disguises itself on a common port. NBAR2 performs deep packet inspection to identify the actual application by signature, enabling classification that port-based matching alone cannot achieve.

Lab Topology

R1 ---- Gi0/1 (WAN-facing interface)

Mixed traffic including a video conferencing
application using dynamic UDP ports that
change per session, making static port-based
ACL matching unreliable

Task 1: Enable NBAR2 Protocol Discovery

Enable protocol discovery on the WAN-facing interface to passively observe traffic composition.

Task 2: Generate Mixed Traffic Including the Video Application

Generate a variety of traffic types, including the video conferencing application using its dynamic ports.

Task 3: Review the Protocol Discovery Statistics

Examine the breakdown of identified applications and their bandwidth consumption.

Task 4: Create a Class-Map Matching the Video Application by NBAR2 Signature

Configure a class-map using match protocol referencing the specific application NBAR2 identified, rather than a port number.

Task 5: Apply Priority Treatment Based on This Classification

Configure a policy-map giving this NBAR2-classified traffic priority queuing, and verify it takes effect despite the application's dynamic port usage.

Solution and Verification

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip nbar protocol-discovery

VideoApp-PC> [initiates a video conferencing
              session, negotiating dynamic
              UDP ports for the session]

R1# show ip nbar protocol-discovery interface gigabitethernet0/1

Protocol                Total       Input        Output
                         (packets)   (packets)    (packets)
webex-meeting            48210       24105        24105
http                     12403       6201         6202
unknown                  3204        1602         1602
-- NBAR2 correctly identified the video
-- conferencing application by signature
-- ("webex-meeting" in this example), despite
-- its use of dynamic UDP ports that would
-- defeat a static port-based ACL entirely

R1(config)# class-map match-all VIDEO-APP
R1(config-cmap)# match protocol webex-meeting

-- "match protocol" referencing the NBAR2
-- signature name, rather than "match
-- protocol udp" combined with a port range
-- that would need constant updating as the
-- application's dynamic ports shift

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class VIDEO-APP
R1(config-pmap-c)# priority percent 15

-- Adding this to the existing LLQ policy
-- from the previous lab, alongside the
-- voice priority queue and CBWFQ classes
-- already configured

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY

VideoApp-PC> [conducts another video call,
              negotiating a DIFFERENT set of
              dynamic UDP ports than before]

R1# show policy-map interface gigabitethernet0/1

    Class-map: VIDEO-APP
      Strict Priority
      (pkts matched/bytes matched) 38942/...
      (total drops) 0
-- The policy correctly matched and
-- prioritized this session too, despite
-- using an entirely different set of
-- dynamic ports than the earlier session
-- NBAR2 initially observed -- confirming
-- classification is based on the
-- application's actual signature, not any
-- specific port number

Key Takeaway

NBAR2's match protocol classification identifies traffic by its actual application-layer signature rather than by port number, making it uniquely capable of consistently classifying applications that use dynamic or non-standard ports — a capability every port-based or ACL-based class-map covered earlier in this series's QoS labs fundamentally lacks, since those approaches would require constant manual updates every time an application's port usage changed.