INE Workbook Vol 1 QoS part 2

The HDLC header is 4 bytes, but complete overhead is 7 bytes per INE. Here is the verification - http://www.javvin.com/protocolHDLC.html .INE actually has an awesome graph showing WAN frame overhead. In short, F/R and HDLC are 7 bytes, whereas PPP is 9 bytes. So to calculate the priority for one VoIP call use g729a (60 byte payload) at a rate of 50pps over a HDLC serial link ....

(60 bytes + 7 bytes overhead)*(50 packets/second)*(8bits/byte) = 26800bps or ~27Kb.

Remaining bandwidth is calculated by taking the overall available bandwidth (75% by default) and subtracting the LLQ classes. I am always confused on if remaining bandwidth is calculated on interface bandwidth, or available bandwidth

To provide bandwidth guarantees while limiting traffic rate, use nested service policies. For example, to limit overall bandwidth to 512k, while providing LLQ for voice at 32k and guaranteed bandwidth for http of 256k:


policy-map CBWFQ
 class VoIP
  priority 32 400
 class WWW
  bandwidth 256
 class class-default
  fair-queue
policy-map Shape
 class class-default
  shape average 512000 10240
  service-policy CBWFQ


Now attach the root policy to the interface.



interface FastEthernet0/0.146
 encapsulation dot1Q 146
 ip address 155.1.146.6 255.255.255.0
 ip rip advertise 10
 service-policy output Shape

Pretty easy to understand, difficult to remember!! Using the above configuration, the 75% rule does not come into play and link queues (control plane traffic) no longer apply and you may wish to define a class for control plane traffic. The same procedure follows policing. When you want to police a subset of overall policed traffic, use nested policy-maps like so...



policy-map Nested
 class R1WWW
   police cir 64000 bc 3200 be 4800
     conform-action set-prec-transmit 1
     exceed-action set-prec-transmit 0
     violate-action set-prec-transmit 0
 class R6WWW
   police cir 64000 bc 3200 be 3800
     conform-action set-prec-transmit 1
     exceed-action set-prec-transmit 0
     violate-action set-prec-transmit 0
policy-map Police2
 class WWW
   police cir 128000 bc 3200 be 4800
     conform-action transmit 
     exceed-action set-prec-transmit 0
     violate-action drop 
  service-policy Nested


MQC allows the nesting of up to three levels of policing.


When doing a dual-rate three-color policer, pay attention when specifying Bc and Be values in addition to the CIR and PIR values. CIR is tied to Bc values, and PIR is tied to Be values, but there are two buckets here - one for CIR and one for PIR. So if PIR is double what you've specified to CIR, your Be will be 2x the Bc value. Using 64k CIR and 128k PIR, with TC of 400ms for CIR and 200ms for PIR, I did the calculations and came up with 3200 for both answers but this is incorrect since there are two buckets. The correct answer is Bc of 3200 and Be of 6400 since you need to add to both buckets at the same time. I hope that makes sense...


Not really useful, but you can apply GTS using MQC on a frame-relay physical interface by matching f/r DLCI. Typically, I attach the service-policy to a map-class and attach the class to a particular DLCI as this give you more granular control for things such as shape adaptive.


When doing MLPPP, f/r traffic shaping is required for PVCs to provide proper QoS properties to engage at the PPP level. MLPPP requires LLQ at the virtual-interface level. LLQ is essential for interleaving since it ensures that scheduler services VoIP packets.Calculate the fragment based on the interface physical rate, not the PVC CIR.


Use QOS pre-classification when using tunnel interfaces. The service policy applied at the interface can see the tunnel encapsulated packets as they cross the interface. The physical interface policy still accounts for header overhead, thus allowing fair scheduling. Otherwise, traffic between two endpoints will be seen as a single flow. You can apply service policies on some tunnel interfaces like GRE, but not IPsec.


With RSVP, the sender sends a PATH message, asking to establish QoS-aware path downstream to the receiver. The path message contains information describing the flow the sender is going to originate. The router compares the parameters in the message with available resources, and provided everything is ok, sends the message. The receiver will respond with a reservation request message towards the sender. The receiver is responsible for requesting specific QoS properties from the network. Once the sender receives the RESV message, it can now send data. Since flows are unidirectional, two reservations must be installed. 


You can simply enable rsvp on an interface with the 'ip rsvp bandwidth' command. You can also configure bandwidth parameters. The default is to use 75% of the interface bandwidth for RSVP and allow the same amount per-flow. You cannot set this higher than 75%. Man RSVP is a different beast. I don't know how many times I've read and labbed it up and I still don't get it....moving on the MLS QOS...


You can set CoS directly in the 3550 switches using the global command 'mls qos cos policy-map'. Using this feature you must set the DSCP marking and set layer 2 marking using the 'set cos' command. This simulates the pass-through feature. Set COS feature only works when you trust DSCP. You can configure 'set dscp' or 'set ip precedence' but not both. 


mls qos cos policy-map
ip access-list st IP_ANY
   permit any
class-map IP_ANY
   match access-gr name IP_ANY


policy-map Classify
   class IP_ANY
       trust dscp
       set cos 2


int fa0/4
service-policy input Classify


With Per-Port Per-VLAN classification, you can match traffic classes inside specific VLANs. Typically these are used for trunk ports but can be used on access ports. You will need two-levels of class-maps. The top level will match Vlan and the 2nd class-map. The 2nd class-map will match the traffic. The policy-map will match the top level classes with respective set actions. This is with 3550. With 3560, you do Per-VLAN QoS by enabling 'mls qos vlan-based' on the physical ports and apply the service policy to the vlan SVI.


You cannot police traffic using a single-level policy-map on the 3560. You create a top-level policy with any 'set' commands or whatnot. From the top level policy, specify the 2nd level police policy.The top level applies to the VLAN globally, where the 2nd level policy may only match port ranges and applies policing to the individual ports. You can also not use class-default. You need a user-defined class to match all traffic.


I need to really remember how to do VLAN qos on the 3560. You need one class-map to match specific traffic, another top level class-map to match the vlan, and match the lower class-map. From the top level, you can use the 'set' commands, police, etc.


Input queues on the 3560 are global and based on SHared Round Robin. The logic is as follows:
1) You may configure one of the queues as priority.
2) If queue is priority, you assign it a bandwidth threshold value expressed in percents from 0% to 40%. Those percents define the amount of internal ring bandwidth available to priority queue.
3) Both Queue 1 and Queue 2 has additional SRR weights, used by the scheduler. 


Service the priority queue up to the max rate, then schedule all exceeding packets using fair round robin scheduling. 


Each queue has three thresholds per queue and by default, they are set to 100%. Third threshold is locked to 'queue full' and cannot be changed. You can still map DSCP and COS values to third threshold. Both queues share buffer space and you can divide it using relative weights in percent. SRR uses WTD - every queue has a # of drop thresholds and you map codepoints to these values.


You can set the buffer limits for specific minimal reserve levels. By default, queues 1 thru 4 use reserve levels 1 to 4 with a value of 100 buffers. You can alter the buffer limit for each level, and then assign queues to different levels.


mls qos min-reserve 7 170 (170 buffers to min-reserve level 7)
int fa0/4
wrr-queue min-reserve 1 7 (assign min-reserve level 7 to queue 1)



SW-4(config-if)#do sh mls qos int fa0/4 buffer
FastEthernet0/4
Minimum reserve buffer size:
 100 100 100 100 100 100 170 170
Minimum reserve buffer level select:
 7 2 3 8
SW-4(config-if)#


All queues configured in shaped mode have absolute weights assigned. 'srr-queue bandwidth shape '. If some weights are zero, then those queues operate in shared mode. For non-zero weights the scheduler places the respective queue in shaped mode. In shaped mode, the system limits the queue sending rate to 1/weight*interface-speed. SRR scheduler guarantees this rate to the queue. For 100mbps interface with a shaped weight of 20, the queue is shaped to 5mbps. Exceeding traffic is delayed. 


All queues not configured in shaped mode operate in shared mode. 'srr-queue bandwidth share . These weights are non-zero. If shaped weight is also non-zero, the scheduler ignores the shared weight and considers it zero in bandwidth share computations. Shared queues share bandwidth remaining after the shaped queues, proportional to their configured weights. 


Threshold 3 is the queue-full threshold. If you are asked drop a specific DSCP pointcode only when the queue is full, map to threshold 3. 'mls qos srr-queue output dscp-map threshold 3 46'.

You can match multiple URL strings with NBAR using regex.

match protocol http url "*.bin|*.t[ea]xt"

Well, that completes the QoS section. Overall, not too bad. If I have time I would like to revist the switching QoS section. I plan to rent some rack sessions from INE and touch the Switching volume and re-visit switching QoS in the same session. Up next is Security! I'm off again for another awesome IPexpert vSeminar!