NBAR (Network-based application recognition)

So I HAVE been studying every night this week, and have found myself putting off my blogging in order to play COD:MW2 :)  So I am going to try and write a couple of these out tonight.  First, NBAR!
 Cisco Link: NBAR!!!

So NBAR provides to your network basically the equivalent of an application layer packet sniffer.  It was originally conceived to assist in providing quality of service more granularly to applications that traverse the network. You can call out things such as http, gnutella, bittorrent, etc....and you router or device can recognize the data and place it, or classify it, however you saw fit.  Here is a good example of an NBAR config:




lunde-edge(config)#class-map match-all MATCH_HTTP
lunde-edge(config-cmap)#match protocol http ? \\this is NBAR
c-header-field Client general Header Field
host Server Host Name
mime Match MIME Type
s-header-field Server general Header Field
url Match URL String \\you can match a url!

lunde-edge(config-cmap)#match protocol http
lunde-edge(config)#policy-map MATCH_HTTP \\create your policy-map
lunde-edge(config-pmap)#class MATCH_HTTP \\bind your class to policy
lunde-edge(config-pmap-c)#drop \\your **action**
lunde-edge(config)#int vlan1
lunde-edge(config-if)#service-policy [input\output] MATCH_HTTP \apply your policy

lunde-edge#show class-map \\display your class-map
Class Map match-all MATCH_HTTP (id 2)
Match protocol http

Class Map match-any class-default (id 0)
Match any

lunde-edge#show policy-map \\display your policy map
Policy Map MATCH_HTTP
Class HTTP_MATCH
Class MATCH_HTTP
drop


Some IOS's have different applications installed on them, but Cisco releases PLDM's, or packet description module language packs that you can install on your system to add more, or to update application signatures. This is a pretty cool feature, that as you can see, can also double as a security measure, stopping unwanted traffic at the application level. I did not show any here (I simply dropped http packets), but you can apply different ip precendence, and DSCP marking to traffic that matches an NBAR match statement.

QoS, Classification and Marking

Wow, 2 days worth of notes to write on here so I will probably just get started.  Again, they probably will not help anyone else out, but I found that if I watch videos/read, and take notes while doing it I get pretty good results.  But if I take those notes, and let them sit for a few days while I ponder them, and them place them into this blog I retain the information much better.  So here we go.

ToS, or type of service markings are used primarily as L3 markings, whereas Cos, or Class of service is L2.
Here are the bits/meanings of them:

Sorry, not the best chart I have ever made up, but this was the interpretation I got from the videos that I watched.  I will see what the exam study guide says bout it in the next couple of days.  Some common L2 markings are as such:

• Frame Relay Discard Eligible (DE) bit (a 1 or 0, 0 if not eligible for discard, 1 if it is)
  
• MPLS experimental bit
• Ethernet trunk CoS (3 bits)

L3 markings are these two:

• DSCP (differentiated services code point)
• IP precedence (older)

So, ToS markings basically can be carried from router to router as they are L3 markings that will survive the hop, unlike L2 markings.  To alleviate some of this, a conversion is done from L2 CoS to L3 ToS, such as a CoS to DSCP conversion.  Traditionally IP precedence could use up to 8 bits, however only used the left-most 3 out of the eight.  DSCP took this a bit further saying "hey, we can use all 8 of those and have some more granular results."  What this became is this:

000       |         000       |        00
PHB (per-hop behavior)       |    drop reliability     |        flow control

Now DSCP is backwards-compatible with ip precedence because of those 3 left-most bits.  Where DSCP differs itself is with the next 3 bits, the drop reliability.  If you look back to that chart above you will see that decimal values 7 and 6 are reserved for network traffic, and that each 0-5 are assigned named values like assured or expedited forwarding.  Now here higher is better; i.e. 101 or 5 is the best rating the packet can get according to the RFC.  000 being the worst.  Drop probability on the other hand is opposite...higher is worse.  Now drop reliability does NOT use all 3 of those bits...only the two left-most ones, so there are three possible combinations:

• 11x (High drop packet)
  
• 10x (Medium drop packet)
• 01x (Low drop)

So these two fields combined make up your DSCP value.  So if you have a
AF13, you have assured forwarding 1, with a drop rating of high
AF41, you have assured forwarding 4, with a drop rating of low
If a router had to choose one to drop it would drop AF13 every time because it has a lower rating in both the IP precedence and drop rating.

They can also be viewed as decimal values:
10 = 001 010 

So be careful when comparing two decimal values in terms of DSCP because higher or lower is not necessarily always better.  Tomorrow night....dadada NBAR.  Cant wait, see you then.

Cisco Modular QoS CLI (MQC)

1. Define class-maps (define "what" to match)
2. Define policy-map (define what to do with your matches)
3. Assign service policy (apply what you have defined to an interface)

2 SHOW COMMANDS
show class-map
show policy-map (interface)

• class-map [word, match-all, match-any]
• match [access-group, protocol, etc...] option
• policy-map [name] ***ONE POLICY MAP PER INTERFACE PER DIRECTION***
  
• class-map [name]
• what do we want to do with it???
•  (interface)service-policy [input, output] [name]