Nbar is a pretty nifty feature.
So today I watched some material on nbar (Network Based Application Recognition), which is a feature originally used for classification of data, used in QoS to mark packets.
It uses very deep packet inspection, to figure out what data is being transfered over the network. It goes up to Layer 7 to figure out what is truly being transfered. This is especially useful for many new applications which uses protocol tunneling to “get through” a firewall. An application that uses this is Skype, which uses port 80, which we all know as web traffic, to carry voip packets. In this case, a regular ACL will not prevent this type of traffic, since we might only block the “skype” port.
Also, the term MQC (Modular QoS Cli), has been branded to my mind. Its basically the combination of three different configuration tasks to perfom QoS.
First there is the class-map, which is used to match traffic, this is where nbar takes place. We can match on many different things. We can make the class-map match all the match clauses, or any of them. Default is all of them. (For example match a protocol, with a certain destination, and we want the class to take effect when both match clauses are met).
Second of, there is the policy-map, which defines what we want to do with certain classes. We can also do alot of things with data conforming to the classes, for example rate limit the traffic, or drop it is another example. We can also mark the packets for further QoS downstream. We might mark the packets as EF (Expedited Forwarding) if it is voip, and we want downstream routers to try and maintain a high level of service.
Third of, we need to apply the policy-map to an interface, in either inbound or outbound direction. Remember, one policy-map, per interface, per direction. This is done with the command: “(config-if)# service-policy inbound MY-POLICY”.
Pretty interesting stuff, tomorrow Ill start hitting the books, with 50 pages awaiting for chapter 1 in the exam guide.