http://www.groupstudy.com/archives/ccielab/200509/msg00464.html --- The key is policing works off internal DSCP values, and unless one is set, you cannot get the egress policer to work. So here ICMP traffic is set to a given DSCP value at ingress, then that dscp is policed at egress. There are lots of other things to consider, like do you want the internal dscp value spoiled to the packet before transmission. You could also look for others ways to set the internal dscp value, like with mls trust dscp if you knew what dscp the icmp packets had. mls qos ! class-map match-all icmp match access-group 100 class-map match-all icmp-out match ip dscp 24 ! policy-map icmp-in class icmp set ip dscp 24 ! policy-map policed class icmp-out police 8000 8000 exceed-action drop ! interface FastEthernet0/2 switchport access vlan 12 switchport mode access service-policy input icmp-in ! interface FastEthernet0/3 switchport mode dynamic desirable mls qos trust dscp ! interface FastEthernet0/4 switchport mode dynamic desirable service-policy output policed ! access-list 100 permit icmp any any --- Subject: RE: CAT 3550 switch again Consider the following: Traffic classified in class cos gets a cos value of 5 What does this mean? If the traffic coming in is not tagged with a .1q or ISL header what relevance does this have? The CoS value is actually determined by the internal DSCP value, so you need to determine how that internal DSCP is set. With wrr-queue cos-map 1 5 you are sending cos 5 (derived from internal DSCP) in to queue 1. With wrr-queue bandwidth you are giving 1/91 parts of the bandwidth with queue 1, is this what you want? As a further exercise, are you clear on how you would configure priority queueing for a different CoS on top of this? Good show commands to become familiar with are Show wrr-queue bandwidth Show wrr-queue cos-map And for extra credit know show mls qos map dscp-cos, this becomes useful when you have to configure the switch to set egress cos to a non-default value based off internal DSCP. --- ---------- Forwarded message ---------- From: Niche To: Jens Petter Eikeland Date: Fri, 16 Sep 2005 17:38:59 +0800 Subject: Re: CAT 3550 switch again Hi, I must say sorry cause I made some error in previous example and I have made some modification, from "wrr-queue bandwidth 4 3 2 1" to "wrr-queue bandwidth 1 2 3 4" There are 4 queues in wrr queueing, this command is to configure how much bandwidth for each queue. The total bandwidth arragement will be the sum of the numbers after the words "wrr-queue bandwidth". 1+2+3+4 = 10 (that means we have divided the total bandwidth (e.g. 100mb) into 10 portions, eacf portion = 10mb). So according to our configuration, queue 4 has 4/10 of the total bandwidth, that's 40mb "wrr-queue cos-map 1 0 1 2 3" "wrr-queue cos-map 2 4" "wrr-queue cos-map 3 6 7" "wrr-queue cos-map 4 5" This is how we can assign each cos valued packet into appropiate wrr-queue, according this configuration, packet has been marked with cos value 0or1or2or3 will be assigned into wrr-queue 1 packet has been marked with cos value 4 will be assigned into wrr-queue 2 packet has been marked with cos value 6or7 will be assigned into wrr-queue 3 packet has been marked with cos value 5 will be assigned into wrr-queue 4 "mls qos map cos-dscp" This command actually is let us to configure a mapping according to the incoming packet pre-defined cos value. cos --> dscp e.g. mls qos map cos-dscp 0 8 16 24 32 40 48 56 cos value = 0 will be map to dscp value 0 cos value = 1 will be map to dscp value 8 cos value = 2 will be map to dscp value 16 ... .. cos value = 7 will be map to dscp value 56 Cheers~ Jacky --- Subject: Re: mls qos trust device cisco-phone vs mls qos trust cos It really depends it's called trusted boundary feature http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12120ea2/3550cr/cli1.htm#wp1863313 ... The trusted boundary feature prevents security problems if users disconnect their PCs from networked Cisco IP phones and connect them to the switch port to take advantage of trusted CoS or DSCP settings. You must globally enable the Cisco Discovery Protocol (CDP) on the switch and on the port connected to the IP phone. If the telephone is not detected, trusted boundary disables the trusted setting on the switch or routed port (sets the trust state to not trusted) and prevents misuse of a high-priority queue. ---- The show policy interface command is not functional on a 3550. You can enter the command, and the IOS will spit out some detail - but it is rubbish. I expect this is some code left over by the developers. Also you have not provided any detail on what your Class-map all-traffic is matching on. Below is a quote from the DocCd 'Do not use the show policy-map interface privileged EXEC command to display classification information for incoming traffic. The interface keyword is not supported, and you should ignore the statistics shown in the display. Instead, you should specify the DSCPs to be monitored by using the mls qos monitor dscp dscp1 ... dscp8 interface configuration command, and then you should use the show mls qos interface interface-id statistics privileged EXEC command. For more information about these commands, see the command reference for this release.' http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225sec/3550scg/s wqos.htm ---- Here is what I was able to determine in the lab regarding MQC to do this and setting up the 3550 to use priority queueing for voice traffic (I had received a unicast question on that). Before starting, please be aware of the following restrictions for QoS on the 3550 QoS Unsupported Global Configuration Commands policy-map policy-map-name bandwidth policy-map policy-map-name set mpls Unsupported Class-Map Configuration Commands match any match destination-address match input-interface match mpls match not match protocol match source-address This is taken from http://www.cisco.com/en/US/products/hw/switches/ps646/products_configura tion_guide_chapter09186a0080211d4f.html#wp1010072 The simple setup is as follows: R1 (F0/0; 10.1.1.1) | | (F0/1) Sw-3550A (F0/2) | | R2(F0/0; 10.1.1.2) I setup the following access list on R2, inbound on F0/0 access-list 100 permit icmp any any dscp cs2 If I ping 10.1.1.2 from R1 I get U.U.U as expected. I now set the dscp to 2 for ICMP traffic on R1 with the following: ! class-map match-all icmp match access-group 110 ! ! policy-map dscp class icmp set dscp cs2 ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 service-policy output dscp duplex auto speed auto ! Access-list 110 permit icmp any any Now if I ping 10.1.1.2 from R1 the ping works and I get hits in the show access-list on R2. R2(config)#do sho access-list 100 Extended IP access list 100 10 permit icmp any any dscp cs2 (20 matches) So far so good, I have a tested base to work from to see how the 3550 operates, I now remove the service policy from R1 F0/0 and see if I can get the 3550 to mark the traffic. Now I put the following configuration on the switch and test class-map match-all icmp match access-group 100 ! policy-map dscp class icmp set ip dscp 16 ! interface FastEthernet0/1 switchport access vlan 12 switchport mode access service-policy input dscp ! access-list 100 permit icmp any any Note that I entered set ip dscp cs2, but the parser changed it to 16. I ping 10.1.1.2 from R1 and it fails. If I add mls qos to the global configuration of the switch, it works. So to reply to Toonsh's original question, was mls qos globally enabled? Also the Set dscp command does not seem to be there, you need set ip dscp, at least in the IOS on my switch. However, the basic functionality works. Now to the question of setting a priority queue for the 3550 for voice traffic. MQC will not work for this, if I try, I get the following: SW-3550A(config-pmap-c)#? QoS policy-map class configuration commands: bandwidth Bandwidth exit Exit from QoS class action configuration mode no Negate or set default values of a command trust Set trust value for the class police Police set Set QoS values This is running 12.1(20)EA, the release I'd expect to see on the exam. There is no option. Now I admit this is tricky, some commands appear in here that are listed as not supported, so I suspect if you use them, you will lose points on the exam. It is easy here though, as the priority keyword is not even listed, so we have to resort to the legacy commands. Now the short cut to doing this is as follows: SW-3550A(config-if)#auto qos voip ? cisco-phone Trust the QoS marking of Cisco IP Phone cisco-softphone Trust the QoS marking of Cisco IP SoftPhone trust Trust the DSCP/CoS marking I was in F0/1 and after selecting the csico-phone option, the autoqos voip macro runs and I get this configuration mls qos map cos-dscp 0 8 16 26 32 46 48 56 mls qos min-reserve 5 170 mls qos min-reserve 6 85 mls qos min-reserve 7 51 mls qos min-reserve 8 34 mls qos ! interface FastEthernet0/1 switchport access vlan 12 switchport mode access 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 Now this typically will not be enough to meet the requirements, and you'll probably want to run no auto qos voip cisco phone on the interace to remove this once you've copied it for further use, but it is a great start to look at the commands you need to configure. So what should we try to accompish here? The auto qos script has created configurations that affect things inbound and outbound. Inbound it is trusting cos from the cisco phone, however the rest is for outbound traffic from the port to the phone, which is where we'll focus here. Each 3550 port has 4 hardware queues, only one of them can be used for priority queuing, queue 4. The interface command priority-queue out sets transmit queue 4 as the priority queue. However, to use priority queuing, you would have to make sure that the CoS value for the packets you want priority queued ended up in transmit queue 4 by some means. The auto qos voip script assumes packets going through the switch to be egressed out interface Fa0/1 will be marked with precedence 5 and places them in queue 4 with the command Wrr-queue cos-map 4 5 So how much bandwidth is assign to the priority queue? The documentation gives us this example: Switch(config)# interface gigabitethernet0/1 Switch(config-if)# 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. " This suggests that the auto qos script has assigned 1/101 to the priority queue, however, the documentation also tells us "All four queues participate in the WRR unless the expedite queue (queue 4) is enabled, in which case weight4 is ignored (not used in the ratio calculation). The expedite queue is a priority queue, and it is serviced until empty before the other queues are serviced" So you never need to set a bandwidth level for the priority queue on the 3550. Chris ----- Venkat, The methodology used at http://www.groupstudy.com/archives/ccielab/200509/msg00464.html can help in verifying all these things. Here is what I did to verify these questions. R1--SWA--R2 R1 (10.1.1.1) can ping R2 (10.1.1.2) I configure the Switch and check its cos to internal DSCP mapping as follows: SW-A#sho mls qos maps cos Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 24 32 40 48 56 mls qos ! interface FastEthernet0/1 switchport mode access mls qos cos 3 At this stage R1 can ping R2, now I apply the following ACL inbound on R2 access-list 100 permit icmp any any prec 3 This is now what happens on R1 R1(config-if)#do ping 10.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: U.U.U Now I add the following to the switch on the interface connecting to R1 SW-A(config-if)#switch trunk encap dot1q SW-A(config-if)#switch trunk nat vlan 1 SW-A(config-if)#switch mode trunk R1 still cannot ping R2. I now add the last piece to the switch interface connecting to R1 SW-A(config-if)#mls qos trust cos And the ping is replied, R1 is now able to ping R2 successfully again. The key here is in understanding what you have to do to set the internal DSCP and how that is used on egress by the switch. So in summary both 1 and 2 are incorrect.. Chris ---- I was a little too hasty on my last post. mls qos cos 3 can work on an access port also. With the following setup R1 -- SWA----R2 R1 can ping R2 with the following setup mls qos interface FastEthernet0/1 switchport mode access mls qos cos 3 mls qos trust cos and R2 has the access list on ingress as follows: access-list 100 permit icmp any any prec 3 So what ishappening is that f0/1 on the switch is trusting COS and setting the internal DSCP to whatever COS value is asociated with teh interface, whichis manually set to 3 regardless of whether the port is an access or trunk port. The internal DSCP is copied to the packet COS (if present) and DSCP (which includes the precedence bits) at egress. So form Venkat's original mail, one is correct and two is incorrect. ---- ---------- Forwarded message ---------- From: Chris Lewis To: Nick Date: Wed, 11 Jan 2006 08:47:22 -0600 Subject: Re: wrr-queue bandwidth command Nick, A good post, but I think one point of detail may be lost here. I think the point of detail is missed both in the original question and in the answer provided. So I think the person that wrote the requirement was missing a point of how priority-queue out works. The priority-queue out command configures the 3550 to use strict priotity scheduling for transmit queue 4. This means that any weighting assigned to queue 4 by the wrr-queue bandwidth is meaningless, as if there is any traffic in queue 4, it will be transmitted regardless of weighting configured for that queue. In essence, when priority-queue out is configured, the bandwidth allocation algorithm ignores weightings assigned to queue 4. The documentation for the priority-queue out command states the following: "When you configure the *priority-queue out* command, the weighted round robin (WRR) weight ratios are affected because there is one fewer queue participating in WRR. This means that *weight4* in the *wrr-queue bandwidth*interface configuration command is ignored (not used in the ratio calculation). The expedite queue is a priority queue, and it is serviced until empty before the other queues are serviced. " This is how it looks on a switch. I configure F0/1 as given. interface FastEthernet0/1 switchport mode dynamic desirable wrr-queue bandwidth 4 6 5 5 wrr-queue cos-map 1 6 7 wrr-queue cos-map 2 0 1 2 wrr-queue cos-map 3 4 5 wrr-queue cos-map 4 3 priority-queue out end Now I look at the following show command. Switch#sho mls qos int f0/1 queueing FastEthernet0/1 Egress expedite queue: ena wrr bandwidth weights: qid-weights 1 - 4 2 - 6 3 - 5 4 - 5 when expedite queue is disabled Cos-queue map: cos-qid 0 - 2 1 - 2 2 - 2 3 - 4 4 - 3 5 - 3 6 - 1 7 - 1 The important part to note is that queue 4 will have weighting 5 only if the expedite queue is disabled. What the configuration given means is that traffic in queue 4 will take whatever it wants, then the remaining queues will have bandwidth allocated as follows, as any weighting assigned to queue 4 when the priority-queue out command is configured, is ignored: Q1: 4/14 - (the figure 14 coming from the sum of weights fro queue 1, 2, 3) Q2: 6/14 Q3: 5/15 Now if I take off the priority-queue command, all your math looks correct to me, as verified by the output below: Switch(config)#int f0/1 Switch(config-if)#no priority-queue out Switch(config-if)#do sho mls qos int f0/1 que FastEthernet0/1 Egress expedite queue: dis wrr bandwidth weights: qid-weights 1 - 4 2 - 6 3 - 5 4 - 5 Cos-queue map: cos-qid 0 - 2 1 - 2 2 - 2 3 - 4 4 - 3 5 - 3 6 - 1 7 - 1 Chris ---