*Traffic can be: Data (citrix,..), Voice (smooth, drop, delay) Video (burst)
*Problem: Lack of bandwidth, Packet Loss, delay, Jitter
*Classification: involves identifying and grouping different trafic types.
*Marking: tags or colors the packet so it can be quickly recognized elsewhere in the network.
*classification and marking should be applied in netwk as close to the source as possible
*Methods deploying QoS: CLI, Modular QoS, Auto QoS, QoS Policy Manager
*Policing: Drop or Marks packets when limit is reached
*Shaping: Queues packet when limit is reached.
*Congestion avoidance: FIFO, Tail Drop, Random Early Detection, WRED weighted random early detection
*Congestion management: queuing
*Link Efficency: Compression , Link Fragmentation + Interleaving
*FIFO queuing produce exessive jitter.
*Configure: 1 configure Class-map, 2 configure policy-map, 3 apply service-policy
*MQC: {class-map1} {class-map2} {class-map3} / { policy-map1} {policy-map2} it creates: class-map1 + policy-map1 / class-map1 + policy-map2 / class-map3 + policy-map2
*match-any != match-all
*Classification: inspecting one or more aspects of a packet to see what that packet is carrying
*Marking: writing information to a packet to identify the classification decision
*Types of marking : layer 2 (Cos) and layer3 (IP precd , Dscp)
*CIR: When calculating cir and mincir for FRTS, use 95 % of the CIR value. If CIR = 256k, it should be used as 256000. Do not multiply 256 with 1024.
*TOS bit setting (SCCP)
0110 1000 1011 1000 (ignoring leading 0's)
0-7 digits represents RTP payload. Maps to DSCP 46 or TOS 5 (leading 3 digits 011)
8-15 digits represents Voice signalling. Maps to DSCP 26 or TOS 3 (leading 3 digits are 101), To change the voice signalling to DSCP 24 (according to CM 4.1 specs) the new value of TOS is 0×000060b8(Change bit 11)
*Qos commands for WAN
fair-queue
fair-queue 128
class-map
match access-group
match ip dscp or match dscp
match ip precedence or match precedence
match input-interface
match protocol
policy-map
class
bandwidth
bandwidth percent
class
bandwidth
queue-limit
*LLQ - Calculating Total bandwidth:
The bandwidth percent allocates bandwidth as a percentage of total bandwidth on link.
For a frame-relay PVC ,if minCIR is configured, total bandwidth = mincir
For a frame-relay PVC , if minCIR is not configured, total bandwidth = cir/2
Default CIR of 56000 bps is applied if no map-class is configured or a map-class with no cir/mincir settings r configured.
*CIR = Bc/Tc (set it to 95% of the actual link speed)
If the link speed is a full T1 (1,544,000), then set the CIR to 1466800
*FRF12 fragments all packets above the specified size. Specify a size greater than voice packet). Voice packets wont be fragmented. Long data packets get fragmented. Voice packets will be interleaved between fragmented data packets…
*RTP header compression for frame interfaces:
int s0/0.1
frame-relay ip rtp header-compression
frame-relay ip rtp header-compression passive
frame-relay ip rtp header-compression iphc-format
ip rtp header-compression ietf-format
*QoS Port configuration
interface fa0/1
mls qos trust cos //trusts packet cos
mls qos trust device cisco-phone // trusts cos only if a phone is attached
switchport priority extend cos 0 // zeros out PC cos values.
*WRED uses random dropping of packets. When threshold 1 is reached (say 25% of queue) packets with Cos 0 and 1 are randomly dropped. When threshold 2 is reached (say 50% of queue), packets with CoS 0,1,2,3 are randomly dropped. At this point packets with Cos 0,1 are more aggresively dropped than packets with Cos 2,3.
*FIFO: 1 queue, no delay gurantee, no BW guarantee, no voice
Priority Queuing: 4 queues, strict priority, delay gurantee, no bw gurantee, no voice
Custum Queuing: 16 queues, Round Robin, no delay gurantee, no voice
*Its generally not recommended to use PQ or CQ . In case you need priority treatment to real time traffic ,then resort to CBWFQ . This has LLQ option( "priority
*Shaping: When a packet arrives , it will check the token bucket if credit available it will be sent to Software queue ( or directly to H/W queue if it is not full ) . If credits are not available then this will be placed in the shapping queue
*LLQ belong to different category . LLQ = Strict Priority Queue + Policing . An Standalone LLQ can not be used for shapping (A PQ can be used
instead of this ).
*wrr-queue bandwidth 1 2 3 4
"The ratio of the bandwidth allocated for each queue is 1/(1+2+3+4),
2/(1+2+3+4), 3/(1+2+3+4), and 4/(1+2+3+4), which is 1/10, 1/5, 3/10, and
2/5 for queues 1, 2, 3, and 4. "
*When doing MQC-based shaping remember that the "shape
average" command automatically sets Be equal to Bc, so set Be explictly to 0
if the task does not require an excess burst. Also remember that if you
want to shape at the DLCI level, using a map-class frame-relay, then you
must shape class class-default.
*This policer has two token buckets, one is defined by Bc and the other by Be, therefore the figures for Bc and Be do not have to be accumulative.
*RED can be applied to an interface or a class.
*RED is in fact a dropping mechanism, and it needs a queue to operate on. As classes are virtual within the router (as opposed to a physical interface) some queueing strategy needs to be defined for the class to define how to build these queues, and for the class-default you are given the additional option of defining fair-queueing.
*There are two other RED options to be familiar with. Flow based (for interfaces only) and the ECN option. Flow based was created for non-TCP flows that do not back off in the presence of dropped packets. The ECN option is where you can set ECN in the packet instead of dropping it, so that you do not have to rely upon the dropping of a packet to signal congestion (and by implication hosts will know to back off without experiencing packet loss).
*The possible values for IP Precedence are(0-7):
000 = 0
001 = 1
010 = 2
...
111 = 7
*The possible values for DSCP are much wider(0-63):
000000 = 0
000001 = 1
.....
111111 = 63
Notice that the first three bits overlap between the two values, DSCP values are fully backward compatible with IP Precedence. For example - you should give voice an IP Precedence of 5 (101). You should give it a DSCP of 46 (101110). Notice that the first
three bits are the same in each case!!! This is what is meant by backwards
compatible.
*When you are operating within a class (for example - the assured forwarding classes (AF)) - you need to be careful about bigger numbers are better. This is not true as you found out. Bigger numbers within the class indicate a higher drop priority. This is a bit counter intuitive, but it is how it works. Notice this is only WITHIN a class, however.
*The Class-Based policer calculates burst as RATE/32. Which represents 1/4 seconds worth of traffic, converted to bytes. Odom discusses this in his book, but I do not know of any good Cisco docs on it. This is VERY different from CAR, which has a rule of thumb which suggests that Bc should be 1.5 seconds worth and Be should be twice that.
*The theory behind police burst values suggests that the bursts should allow a full TCP window at the configured rate. The window is calculated as RATE
times Round Trip Time / 8 to convert to bytes. This would suggest that by
default Cisco assumes a 250 ms RTT.
*If you want to use CBWFQ with the Class-Based Traffic Shaping mechanism, the following conditions must be met:
A secondary-level (child) policy map must be created. This secondary-level (child) policy map is then used to configure CBWFQ by enabling the bandwidth command.
Traffic shaping must be configured in the primary-level (parent) policy map.
*If random detect dscp is configued as the drop policy with no further customization the previous link describes the default behavior. But in summary, each marking has the same probaility of being dropped, but some become eligible for being dropped at different queue depths. As an example if the average queue depth in a class for af31 traffic reaches 32 packets, all further af31 packets are eligible to be randomly dropped. Whereas for af3, packets are eligible to be dropped when the average queue depth is 24 packets.
*A large gap between the maximum threshold for exceeding packets compared to
the minimum threshold for conforming packets is there to ensure that the
instantaneous queue depth will never reach the minimum threshold of the
conforming traffic and hence exceeding packets will be dropped ahead of
conforming packest at all times.
No comments:
Post a Comment