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 unreliableTask 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-discoveryVideoApp-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 entirelyR1(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 shiftR1(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 configuredR1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICYVideoApp-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 numberKey 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.