Sunday, January 31, 2010

Shaping and Policing Traffic

Sorry I have been quiet lately.  Been reading alot in the Exam Guide, and hitting some labs up.  I recently downloaded the INE V1 Free Chapter, which was actually QoS stuff, and worked through it.  I grabbed some pretty good info, inluding how to configure sla monitors as jitters to generate voice traffic on a network.  Heres the config for that:


[on the router you want to generate traffic]
ip sla monitor 1
 type jitter dest-ipaddr 172.16.11.3 dest-port 16384 codec g729a
 freq 1
timeout 1000
ip sla monitor schedule 1 life forever start-time now

[on the router you want to send packets back]
rtr responder, OR ip sla monitor responder


You can of course change the port numbers, ip address, and codec used.  It works pretty darn good if you want to make sure your classes and or policies are doing what they are suppose to.

I was also going through the Lab Portfolio for the exam and found a couple of different ways to police and shape traffic.  You can actually do it in your policy-maps, or at the interface level which is the legacy configuration method.  The policy-maps just allow you a bit more granularity, and flexibility as you can apply them to multiple interfaces.  Here are the configs:

Traffic Shaping 

[GTS (Generic Traffic Shaping)]
interface multilink 1
traffic-shape rate

[MQC]
policy-map DEFAULT_SHAPING
 class class-default
  shape average [bps]
interface multilink 1
 service-policy output DEFAULT_SHAPING


Rate-Limiting (aka policing)

[CAR (committed access rate policing)]
interface multilink 1
rate-limit output 56000 1500 4000 conform-action continue exceed-action drop

[MQC]
policy-map DEFAULT_POLICING
 class class-default
  police rate 56000 conform-action transmit exceed-action drop
interface multilink 1
 service-policy output DEFAULT_POLICING


Now you can do other things that transmitting or dropping the packets like marking, or re-marking them.  I just wanted to show you all a basic example of how this could be done within a policy-map, or at the interface level.  Good to know more than one way to do things when troubleshooting a problem, or attempting the CCIE lab :)

Good link:http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml

Friday, January 15, 2010

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.

Sunday, January 10, 2010

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.

Friday, January 8, 2010

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]

Thursday, January 7, 2010

QOS

So I began yet another QOS venture tonight. Watched the nuggets video(s). Here are just some random notes. They will probably be of no use to anybody but me, but here they are:

TOP NETWORK CULPRITS (in terms of good service over the wire!)
  1. Lack of bandwidth
  2. Packet loss
  3. Delay
  4. Jitter (variation of delay...i.e. on packet has 20ms delay, next 5, next 55...
QOS MODELS
  1. Best Effort (it gets there when it gets there!! like a bitchy old mail lady who is disgruntled with her job)
  2. Integrated Services Model (reserved bandwidth from point A ----> point B using RSVP) intserv
  3. Differentiated Services Model (this is the best...puts up and breaks down as packets traverse interface)
IMPLEMENTING QOS
  1. Do a network audit and identify the critical applications
  2. Identify the application requirements (i.e. what protocols...bandwidth...etc)
  3. Divide that traffic into groups (i.e. classify it into approx. 4-11 groups)
  4. Create and apply policy to those groups
-Qos is basically just classifying and marking traffic

CONGESTION AVOIDANCE MECHANIMS
  1. FIFO and Tail-drop
  2. Random early detection (RED)
  3. Weighted random early detection (WRED)
-Policing traffic drops all packets after a certain threshold is reached (i.e. you say no more after 200kbps)
-Shaping traffic merely queues packets when a pre-defined limit is reached

METHODS OF IMPLEMENTING QOS
  1. CLI (hardest method)
  2. MQC (modular QOS CLI)
  3. AutoQOS (cisco proprietary)
  4. SDM
  5. QPM (plug-in of CiscoWorks)

Wednesday, January 6, 2010

POTS setup on FXS ports

Here is just a basic setup where the two routers have FXS ports with regular analog telephones sitting on them. The two routers are connected via some kind of ethernet link, and share IP addresses on the same subnet. Here is the visio with embedded configs:




Also just some basic "show" commands to post here:
show voice port summary
show dial-peer voice summary
debug voip dial-peer

....noted

Monday, January 4, 2010

Back for the ONT!

Sorry dudes...been out for the holidays. Back and cranking on the ONT. Passed the ISCW a while back with a decent score, but really want to kill this one to complete the CCNP. Here we go...

Default Cisco Voice sample size is 20ms
***Large sample sizes cause more coding delay, and result in greater, more noticeable ruined audio if the packet is lost or dropped.

http://www.voip-calculator.com/calculator -- a good voip calculator


Total packet size/payload size = total bandwidth requirement/total codec requirement
so to get total bandwidth requirement take:
total packet size * codec requirement / payload size = total bandwidth required

so for G.729 on a frame relay take this:
(6 (for frame header)+40 (l3 and l4)+ 20 (payload size for g.729) * 8kbps (codec req.)
_________________________________________________________________________________
20 (payload size for g.729)

= 26.4 kbps(multiply by total number of calls you expect at 1 time)

VAD- Voice activity detection is a mechanism that stops sending traffic during periods of silence

Thats a start. Also watched the VOIP design considerations video. Contained tidbits about call managers, phones, voip design models, and call admission controls.