NBAR: An Overview Cisco Forum FAQNBAR: An Overview (#11158) | ||
| NBAR (Network-Based Application Recognition) NBAR 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 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 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 builtin 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: »www.cisco.com/pcgi-bin/tablebuild.pl/pdlm 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]? Accessing tftp://192.168.1.254/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) london-colo-east-01-e-01#sh flash: 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.)* Reference the pdlm in the config: london-colo-east-01-e-01#conf t Enter configuration commands, one per line. End with CNTL/Z. london-colo-east-01-e(config)#ip nbar pdlm bittorrent.pdlm london-colo-east-01-e(config)# ! ip nbar pdlm bittorrent.pdlm ! 3.) Create a class-map and policy map and apply it to the interface concerned: class-map match-all bittorrent match protocol bittorrent ! policy-map bittorrent-policy class bittorrent drop ! interface FastEthernet0 no ip address ip address 192.168.1.1 255.255.255.0 ip access-group to-internet in ip nat inside service-policy input bittorrent-policy speed 100 full-duplex ! 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 by setting the precedence bits, etc 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 should be the suggested reading for any more indepth look at policy-maps. by Covenant | ||