auto qos voip cisco-phone and ingress queues

[sarahr202]

Hi everybody.

When we use " mls qos trust device cisco-phone', will it also set up ingress priority queues?

For e.g  consider the example below:

Switch-A(config)#interface fastEthernet 0/5
Switch-A(config-if)#auto qos voip cisco-phone


Switch-A#sh run int fa0/5Building configuration...


Current configuration : 487 bytes
!
interface FastEthernet0/5
 switchport access vlan 10
 switchport mode dynamic desirable
 switchport voice vlan 100
 mls qos trust device cisco-phone
 mls qos trust cos
 auto qos voip cisco-phone
 wrr-queue bandwidth 10 20 70 1
 wrr-queue min-reserve 1 5
 wrr-queue min-reserve 2 6
 wrr-queue min-reserve 3 7
 wrr-queue min-reserve 4 8
 wrr-queue cos-map 1 0 1
 wrr-queue cos-map 2 2 4
 wrr-queue cos-map 3 3 6 7
 wrr-queue cos-map 4 5
 priority-queue out spanning-tree portfast

Above " priority-queue out" is shown, Does it mean only egress priority queue not ingress priority, is configured as a result of using '

mls qos trust device cisco-phone" ? 

thanks and have a great weekend.

[singhaam007 · Accepted solution]

Hello Sarah,

Yes you are correct. But its good to use threshold values to 100.

sh mls qos map cos-input-q

   Cos-inputq-threshold map:

             cos: 0   1   2   3   4   5   6   7

             ------------------------------------

 queue-threshold: 1-1 1-1 1-1 1-1 1-1 2-1 1-1 1-1

this will map Cos 5 to queue 2 and threshold1 but it’s always good to map cos 6 into the same queue as cos 5. You can select different threshold for cos 6 traffic.

Yes you are correct about input queues.

For egress queues, you are talking about shape command here not share ..

If you shape 25 % of bandwidth to q1 then other queues can’t take it if there is congestion. Because this actually reserve the amount of bandwidth for the queue so its always good to use share command.

Check this one for egress QOS

http://blog.ipexpert.com/2011/08/25/campus-qos-part-3-egress-queuing-dropping-and-scheduling/

thanks

[sarahr202]

Hi Sigh

thanks for the link.

Rack18SW1(config)#int f0/10

Rack18SW1(config-if)#priority-queue out

This will always be queue 1 and is not configurable.

Above will priority queue get serviced first just like in case og ingress queues?

Is my understanding correct?

Quote from the attachment:

And before I leave you there is this final thing I want to show.

That is how to limit the egress traffic on an interface with the SRR command.

Let’s say that We have a 100 Mbit interface but customer only pays for 4 Mbit.

We can use this command.

Rack18SW1(config-if)#srr-queue bandwidth limit ?

    enter bandwidth limit for interface  as percentage

Let say we configure :

Rack18SW1(config-if)#srr-queue bandwidth limit 10

Rack18SW1(config-if)#srr-queue bandwidth shape 25 0 0 0

Which command will take precedence? This is what I understand:

By configuring bandwidth limit 10, we are saying upto 10 percent of port's bandwidth can be used by egressing packets from all egress queues.

By configuring srr-queue bandwidth shape 25 0 0 0, we are saying queue1 1 can use upto 25 percent port's bandwidth. But packets from queue1 will be dropped well before that because we configured bandwidth limit 10 percent under the port.

Is my understanding correct?

thanks

[singhaam007 · Accepted solution]

Hello Sarah,

i tried my best to explain all you questions but plz forgive if there is any mistake coz i am still learner.

but please ask as many question you want and will help you.

please check this attachment

thanks

[sarahr202]

Hi Sigh

I really appreciate your help and the way you took time time to explain things. I am very grateful to you for that.

I am going to work ; I will read those attachment when i get back

Thanks and have a great day.

[singhaam007 · Accepted solution]

You can check this default behaviour by this command and see which queue that interface mapped.

Switch># show mls qos interface gigabitethernet1/0/2 queueing

GigabitEthernet1/0/2

Egress Priority Queue :enabled

Shaped queue weights (absolute) :  25 0 0 0

Shared queue weights  :  25 25 25 25

The port bandwidth limit : 100  (Operational Bandwidth:100.0)

The port is mapped to qset : 1

thanks

[sarahr202]

Hi Sigh

Quick question about internal qos label.

So far I learned how  we can map cos or dscp value to different ingress queues.  I also learned  why  switch has a cos -dscp map  incase if egress port  is not trunk but a layer 3 interface, cos -dscp map can be used to find corresponding dscp value which can be be carried by outgoing packet.

But I am still puzzled what is internal qos label.

The following is the code from the attachment about internal qos label:

It is important to know that the Catalyst switch uses a concept of an

internal QoS label. This is a DSCP value which is used internally and

will define into which queues the traffic ends up.

But I have seen in the attachment how cos or dscp can be mapped to a  ingress queue.  But the above paragraph from the attachment says it  the dscp value which determines which queue the frame/packet ends up in.

I have seen cos can be mapped to a ingress queue  which therefore can decide which queue the frame.packet end up in.

Following is the extract from the link you forwarded ( ipexpert link)

The first step on the egress side of the switch is to map each frame to one of 4 egress queues and assign a threshold value that is used by Weighted Tail Drop (WTD). We’ll talk about WTD in a little while but for now just consider that each frame is placed in Q1 thru Q4 based on DSCP or COS depending on the QoS label. “QoS label”- what’s this? At the ingress switchport we can either trust/set layer 2 or layer 3 markings using “mls qos trust cos” or “mls qos trust dscp” at the ingress port or alternatively a service-policy. This marking is then copied across internally within the switch and forms the QoS label. This is used for all future QoS-related actions on the frame whilst inside the switch. This includes deciding which queue/threshold the frame is placed into on both the ingress and egress side.

I hope you could elaborate on it.

thanks

[singhaam007 · Accepted solution]

hello Sarah,

hope fully this will help.

thanks

[sarahr202]

Hi Singh.

That is what I understood after reading few links.

It is important to know that the Catalyst switch uses a concept of an
internal QoS label. This is a DSCP value which is used internally and
will define into which queues the traffic ends up.

QOS internal label could be dscp or cos.

for example: ( quote from the link)http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/

In the 3550 this label is simply a special “internal” DSCP value. However, in the 3560 the QoS label format is more complicated, and allows storing either CoS or DSCP information

At the ingress switchport we can either trust/set layer 2 or layer 3 markings using “mls qos trust cos” or “mls qos trust dscp” at the ingress port or alternatively a service-policy. This marking is then copied across internally within the switch and forms the QoS label. This is used for all future QoS-related actions on the frame whilst inside the switch. This includes deciding which queue/threshold the frame is placed into on both the ingress and egress side

In summary, Qos label will decide which queue packet will end up in. Qos label could be dscp value or cos in case of cat 3560 switch while in case of cat 3550, qos label is dcsp value.

So qos label could be cos or dscp depending upon the switch .

Let consider only 3550 switch.

if we have a cat switch 3550, and  our switch is configured to set the cos to 4 for  at the ingress port, then switch will first compute the qos label which is essentially dscp value using cos-to dscp table. Once the qos label ( dscp value is computed) switch will place the frame to the queue that is mapped to dscp value.

If iam corect then please consider this scnario

We have cat 3550 switch, with four ingress queues: q1,q2,q3,q4

Let say  we have mapped cos 3 to q1
Let say we have mapped dscp 7 to q2.

we also configure the cos to dscp mapping as:

cos 3-----dscp 7.

our switch is configured to trust cos at the ingress port.  Suppose our switch receives a frame with cos 3,
What will switch do?

will the switch place the frame in q2 because switch computes the qos lable using cos to dscp and finds dscp value 7 is mapped to cos 3 and therefore places the frame in q 2?

Will the switch place the frame in q1 because cos 3 is mapped to q1 ?

This is my understanding.
Switch( 3550) uses qos lable to decide in which queue to place the frame/packet. Therefore sw should place the frame in queue 2.

Is my understanding correct?

Once again thanks for your help and i have learned a lot from you about QOS.

[singhaam007 · Accepted solution]

Hello Sarah,

lets see if this helps.

please ask as many questions you want.

thanks

[sarahr202]

Hi Singh

The following diagram displays stages of QoS processing in a typical Catalyst switch.

We are now considering the Classification and Marking stage.  The switch uses local policy configuration to classify input packets.  The local policy may be as simple as port QoS settings or more  complicated, such as policy-maps with QoS ACLs. The result of  classification stage is the internal QoS label (e.g. internal DSCP value  with the 3550). At this stage, the switch uses special globally  configurable QoS mapping tables. The tables map one QoS marking  “type” to another, e.g. CoS values to DSCP, or DSCP to CoS. You can  display the tables using the command show mls qos map.

The result of classification is qos label ( internal dscp value). From that point on, this  internal dcsp value is used to queue traffic at ingress before the ring and also to queue the traffic at egress before the traffic is sent out the interface/port.   Am I correct so far?

Please  look at the above figure the portion "  Police and remark"  

I just want to confirm  the term : "remark"

This is what i understood.

Let say we our switch is configured to trust COs . A frame is received with cos 3. Switch uses its port setting or qos acl or just use the cos -dscp map to determine the internal dscp value which is7  as an example.

The switch then also remark the dscp value in the received frame as 7 ( according to its cos -dscp map).

Is that the term  " remark" the above figure is refering to?

Thanks and and I appreciate your patience.

[singhaam007 · Accepted solution]

Hello,

In Classification and Marking stage packets will get remarked according to the configured classification and policer information. All packets that belong to a classification can be remarked. When you configure a policer, packets that meet or exceed the permitted bandwidth requirements (bits per second) can be conditionally passed through, dropped, or reclassified

Switch(config)# policy-map Example

Switch(config-pmap)# class class-default

Switch(config-pmap-c)# set ip dscp 1

Switch(config-pmap-c)# exit

Switch(config-pmap)# class AF31-AF33

Switch(config-pmap-c)# set ip dscp 3

Switch(config-pmap-c)# exit

Switch(config-pmap)# exit

Switch(config)# interface fastethernet0/1

Switch(config-if)# service-policy input Example 

Switch(config-if)# exit

In this example by using command set ip
  dscp 1 you remarking the incoming packet.

As soon as packets comes in switch will
check  the cos or Dscp value and then
  remark it if there is any service 
 policy for classification and then 
route it to its destination.

thanks

[sarahr202]

Hi Singh

The following diagram displays stages of QoS processing in a typical Catalyst switch.

We are now considering the

Classification and Marking

stage.  The switch uses local policy configuration to classify input  packets.  The local policy may be as simple as port QoS settings or  more  complicated, such as policy-maps with QoS ACLs.

The result of  classification stage is the internal QoS label (e.g. internal DSCP value  with the 3550)

I understood the end result of " classify and mark" is computation of internal qos label which is in our case is dscp value.

Please focus on " police and remark" as shown in above fig.

I am going to use scenario .

Let say a switch is configured to trust cos. Our switch receives a frame with cos 3. Our switch computes the internal qos dscp value as 7 after following the configured qos policy. This is the end result of " classify and remark" step.

Now the frame or packet is handed over to policer. Policer will either drop,pass or remark the packet or frame.

Let say our switch decides to remark the packet or frame according to the configured policer.

Now What is re-marked as a result of policer? Is it cos or dscp?

What will be used to finally queue the packet or frame at ingress i.e after a frame has gone through "Classify and mark' step which resulted in inner qos label DSCP 7 and " policier" which decides to re-mark the frame/packet?

My understanding is (after a long discussion ) switch uses dscp value eventually to queue the packet at ingress. So if policer decides to remark the frame/packet, it has to be dscp .

And this final dscp value is used to queue the packet/frame at ingress.

Am i correct?

Thanks Singh. I really admire you for patience.  QOS is not covered in CCNP( routing/switching), in detail, I intended to just get the very basics of QOS. But I found   discussion with you very interesting and that prompted me to discover more and more about qos.

You have a great day.

[singhaam007 · Accepted solution]

Hello Sarah,

hope this will help.

thanks

[sarahr202]

Hi Singh.

I understand the basics of qos.  However, I have a question about policing for example:

Distribution1(config-cmap)#policy-map sample-policy2Distribution1(config-pmap)#class Class-ADistribution1(config-pmap-c)#police 10000000 8000 exceed-action drop        

I understand the traffic fitting the profile of class -A above will be policed upto 10 Mbs. But what is 8000?

thanks and have a great weekend.

[singhaam007 · Accepted solution]

Hi Sarah,

You can also assign burst size with any police so it wont drop the packet straight way after reaching to police limit. In short cut, it is a bit extra bandwidth for the queue before it actually drops the packet.

Its always good to have some burst so packets wont drop soon in congested network.

Burst—defines the maximum amount of tokens the bucket can hold at any time. Supported bursts range from 8000 bytes to to 2000000 bytes, and increment by 64 bytes

Hope this will help.

thanks