how-to block ads
NBAR (Network-Based Application Recognition) is a very indepth topic hence this FAQ will try to illustrate one of its many functionalities and how to action packets that match the protocol criteria required.
NBAR has its niche within the QoS (Quality of Service) crowd where specific applications are given precedence or not as the case maybe depending on the network requirements at the time of the implementation. NBAR allows recognition of a wide variety of applications where QoS may be implemented on them, i.e. from the bandwidth intensive Citrix to the port changing Kazaa P2P (Peer-to-Peer) application.
NBAR allows the classification of protocols from layer 4 to 7 hence allowing the router in some respects to disregard its layer 3 position and to look at the high layer protocols. NBAR can recognise:
Statically assigned TCP and UDP port numbers
Non-UDP and non-TCP IP protocols
Dynamically assigned TCP and UDP port numbers. Classification of such applications requires stateful inspection; that is, the ability to discover the data connections to be classified by parsing the connections where the port assignments are made.
Sub-port classification or classification based on deep packet inspection; that is, classification by looking deeper into the packet.
NBAR can classify static port protocols. Although access control lists (ACLs) can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when using ACLs.
NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are transversing an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol Discovery maintains the following per-protocol statistics for enabled interfaces: total number of input and output packets and bytes, and input and output bit rates. The Protocol Discovery feature captures key statistics associated with each protocol in a network that can be used to define traffic classes and QoS policies for each traffic class.
The router (depending on model and IOS version) has built-in NBAR functionality which may be seen when configuring NBAR:
london-colo-east(config-cmap)#match protocol ?
Or when scrutinising a port-map:
london-colo-east-01-e-01#sh ip nbar port-map
which will demonstrate the ports and IP protocol of the various protoocols present.
An external Packet Description Language Module (PDLM) can be loaded at any time to extend the NBAR list of recognized protocols. PDLMs can also be used to enhance an existing protocol recognition capability. PDLMs allow NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload, hence PDLMs allow the router to gain the functionality of recognising applications at the application layer for the protoocols which when the router was shipped, was either not available or have changed in its function so much that an update is required.
To view a list of currently available PDLMs or to download a PDLM:
NBAR Packet Description Language Module Download
There are a number of examples, such as Citrix, gnuttella, skinny, etc. This type of traffic would have been hard to classify using standard QoS tecniques, either to minimise the impact of such programs on bandwidth, to drop them or to allocate the most amount of bandwidth to. PDLMs give the router this added ability to recognise the traffic specified by it as well as some other types of traffic pre-defined in the IOS.
Procedure (* optional if application NBAR required on is already present:
CEF should be enabled.
1.)* Copy the pdlm into the router's flash:
london-colo-east-01-e-01#copy tftp flash
Address or name of remote host ? 192.168.1.254
Source filename ? bittorrent.pdlm
Destination filename [bittorrent.pdlm]?
Erase flash: before copying? [confirm]n
Loading bittorrent.pdlm from 192.168.1.254 (via FastEthernet0.1): !
[OK - 4125 bytes]
Verifying checksum... OK (0xA1BF)
4125 bytes copied in 0.192 secs (21484 bytes/sec)
System flash directory:
File Length Name/status
1 9773168 c1700-k9o3sy7-mz.123-10.bin
2 4125 bittorrent.pdlm
[9777424 bytes used, 6737644 available, 16515068 total]
16384K bytes of processor board System flash (Read/Write)
2.) Enable CEF
3.)* Reference the pdlm in the config:
4.) Create a class-map and policy map and apply it to the interface concerned:
Basically, within the policy-map bittorrent-policy, the action for any packets matching that protocol arriving on the fa0 interface was to DROP them. Packet manipulation is possible using QoS such as setting the precedence bits or setting maximum/limited bandwidth for further processing down the line but in this instance, the packets are set to be dropped as soon as they arrive on the fa0 interface.
QoS (Quality of Service) and NBAR
QoS should be the suggested reading for any more indepth look at policy-maps. As illustration, following is sample configuration using NBAR and QoS CBWFQ (Class-Based Weighted Fair Queue) for most common P2P protocols.
Unlike the previous sample configuration where P2P traffic is dropped or blocked, this sample configuration objective is to permit with restriction. The restriction is that all P2P traffic will be limited to only 8 kbps bandwidth. Any attempt from P2P traffic to use more than 8 kbps bandwidth will be dropped or blocked.