NBAR Examples (CLI and SNMP)
The following examples provide a systematic introduction to configuring and monitoring NBAR via the CLI.
Basic NBAR Configuration
In this configuration, NBAR Protocol Discovery is enabled on the VIP card of a Cisco 7500 router on serial port 6/1/2. Note that Distributed NBAR does not require different commands than NBAR.
router(config-if)#interface serial 6/1/2 router(config-if)#ip nbar protocol-discovery
This show command displays the discovered protocol, ranked by number of packets:
router# show ip nbar protocol-discovery interface serial 6/1/2 top-n
Serial6/1/2
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
------------------------ ------------------------ ----------------------
netbios 154540 0
13981136 0
0 0
0 0
rtp 54015 9
6059862 1384
0 0
0 0
Some optional parameters to show ip nbar protocol-discovery, such as bit-rate, byte-count, max-bit-rate, and packet-count statistics, allow more precise display.
To monitor the NBAR Protocol Discovery results with SNMP, the first step is to retrieve cnpdAllStats parameters, where protocols are classified by two indexes:
cnpdTopNConfigIndex uniquely identifies an entry in the cnpdTopNConfigTable table.
cnpdTopNStatsIndex uniquely identifies an entry in the cnpdTopNStatsTable table.
In this example, we are interested in the netbios entry:
SERVER % snmpwalk -c public -v 2c martel cnpdAllStatsTable | grep netbios CISCO-NBAR-PROTOCOL-DISCOVERY-MIB::cnpdAllStatsProtocolName.15.26 = STRING: "netbios"
The next example displays all entries that contain two indexes. The first one (15) represents the ifIndex of the interface where NBAR is enabled. ifIndex 15 corresponds to serial 6/1/2 in this example (taken from the IF-MIB table). The second index (26) represents a unique NBAR protocol index. The index 26 corresponds to the netbios entry. As a result, all NetBIOS traffic on the serial interface 6/1/2 is displayed. The cnpdAllStatsTable table contains the input packet count, byte count, 5 min Bit Rate, and 5 min Max Bit Rate from the previous show command:
snmpwalk -c public -v 2c martel cnpdAllStatsTable | grep 15.26 CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsProtocolName.15.26 = STRING: "netbios" CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsInPkts.15.26 = Counter32: 154540 packets CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsOutPkts.15.26 = Counter32: 0 packets CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsInBytes.15.26 = Counter32: 13981136 bytes CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsOutBytes.15.26 = Counter32: 0 bytes CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsHCInPkts.15.26 = Counter64: 154540 packets CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsHCOutPkts.15.26 = Counter64: 0 packets CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsHCInBytes.15.26 = Counter64: 13981136 bytes CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsHCOutBytes.15.26 = Counter64: 0 bytes CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsInBitRate.15.26 = Gauge32: 0 kilo bits per second CISCO-NBAR-PROTOCOL-DISCOVERY-MIB:: cnpdAllStatsOutBitRate.15.26 = Gauge32: 0 kilo bits per second
All counters are duplicated in the table: once for the 32-bit counters, and once for the 64-bit HC counters (HC stands for High Capacity).
Finally, the following command monitors the NBAR resources:
Router# show ip nbar resources
NBAR memory usage for tracking Stateful sessions
Max-age : 120 secs
Initial memory : 1751 KBytes
Max initial memory : 5837 KBytes
Memory expansion : 68 KBytes
Max memory expansion : 68 KBytes
Memory in use : 1751 KBytes
Max memory allowed : 11675 KBytes
Active links : 36
Total links : 25753
Custom Application Example
If the traffic of interest is not monitored by Protocol Discovery, the NBAR custom application is the option. For example, the custom protocol myapp looks for TCP packets with a destination or source port of 9999:
router(config)# ip nbar custom myapp tcp 9999 router# show ip nbar port-map myapp port-map myapp tcp 9999
In the following example, the custom protocol media_new identifies TCP packets with a destination or source port of 4500 and that have a value of 90 at the sixth byte of the payload:
router(config)# ip nbar custom media_new 6 decimal 90 tcp 4500In this case, NBAR examines packets containing source or destination port 4500. If the sixth byte contains decimal 90, a session cache entry is made, and all subsequent packets of that specific session are classified in "media_new" until a FIN or RESET is detected. For fragmented packets, NBAR looks at the first fragment of a fragment set to see if it contains the value. The rest of the fragment set is classified the same without actually looking into the fragmented packets.
In the last example for the NBAR custom application, the custom protocol app_sales1 identifies TCP packets that have a source port of 4567 and that contain the term SALES in the fifth byte of the payload:
router(config)# ip nbar custom app_sales1 5 ascii SALES source tcp 4567These custom applications generate entries in Protocol Discovery, both in the output of show ip nbar protocol-discovery and in the NBAR MIB.
Limiting Peer-to-Peer Traffic
These example analyzes Gnutella, which uses six well-known TCP ports: 6346, 6347, 6348, 6349, 6355, and 5634. The configuration and the show output are as follows:
router(config)# ip nbar port-map gnutella tcp 5634 6346 6347 6348 6349 6355 router# show ip nbar protocol stats byte-count FastEthernet0/0 Input Output Protocol Byte Count Byte Count ------------------------------------------------ gnutella 43880517 52101266
Creating a QoS service policy using the commands of the modular QoS CLI (MQC) allows policing the traffic classified by NBAR, which is Gnutella in this example:
router(config)# class-map gnutella router(config-cmap)# match protocol gnutella router(config-cmap)# exit router(config)# policy-map sample router(config-pmap)# class gnutella router(config-pmap-c)# police 1000000 31250 31250 conform-action drop exceed-action drop violate-action drop
HTTP Requests Payload Inspection
This example classifies the HTTP traffic according to the URL's content. If the keyword "ebay" is discovered in the URL, the traffic is classified and accounted. Furthermore, MQC allows actions such as policing, rate-limiting, and adjusting the precedence. In this case, a new precedence of 5 is assigned to all eBay traffic:
router(config)# class-map match-all ebayclass router(config-cmap)# match protocol http url "*ebay*" router(config)# policy-map ebaypolicy router(config-pmap)# class ebayclass router(config-pmap-c)# set ip precedence 5 router(config)# interface Serial6/1/2 router(config-if)# ip nbar protocol-discovery router(config-if)# service-policy input ebaypolicy router# show policy-map interface serial 6/1/2 Serial6/1/2 Service-policy input: ebaypolicy Class-map: ebayclass (match-all) 4 packets, 495 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol http url "*ebay*" QoS Set precedence 4 Packets marked 4 Class-map: class-default (match-any) 104 packets, 9590 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
The NBAR HTTP possibilities go well beyond what this example shows. Indeed, NBAR is not limited to inspecting the URL's content, but also the server accessed by the HTTP requests, or the MIME type in the HTTP payload can be taken into account. For example, you could classify all traffic containing jpeg or mpeg files.
