Hi,
I am trying to understand the reason for egress packet drops I am seeing on our 3560s.
The switches are wkgrp switches directly connected to users. We use Nortel IP phones with the phone inline with the user PC. PCs auto-neg to 100/full
As a reminder, Nortel phones mark voice traffic dscp 46 and COS 6, sig traffic dscp 40 and cos 5, and data traffic 0/0
The typical port configuration is :
switchport mode access
switchport voice vlan 100
priority-queue out
mls qos trust dscp
spanning-tree portfast
end
Global qos config is:
mls qos map dscp-cos 46 to 6
mls qos map cos-dscp 0 8 16 24 32 40 46 56
mls qos srr-queue input bandwidth 98 2
mls qos srr-queue input buffers 95 5
mls qos srr-queue input priority-queue 2 bandwidth 1
mls qos srr-queue input dscp-map queue 1 threshold 1 40
mls qos queue-set output 2 threshold 1 3100 3100 100 3200
mls qos queue-set output 2 buffers 10 75 5 10
mls qos
What I am seeing is persistent drops from Egress q 1-1
While I know this can happen during bursts, this seems to exceed what I would expect for the low-level usage Im seeing on the interface. Here are stats from 5 mins after doing a clear mls qos int stat
FastEthernet0/17
dscp: incoming
-------------------------------
0 - 4 : 53078 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 29 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 77308 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 29 0 0 0 0
45 - 49 : 0 0 0 549 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 53099 0 0 0 0
5 - 7 : 0 29 0
cos: outgoing
-------------------------------
0 - 4 : 80501 0 0 0 0
5 - 7 : 29 553 0
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 33 0 0
queue 1: 80164 86 615
queue 2: 0 0 0
queue 3: 549 0 260
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 490 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
MainStack2#sh int fa0/17
FastEthernet0/17 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0011.93c1.0713 (bia 0011.93c1.0713)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
...
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
...
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 83286
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 128000 bits/sec, 153 packets/sec
5 minute output rate 1653000 bits/sec, 227 packets/sec
14551956 packets input, 1566102266 bytes, 0 no buffer
Received 9428 broadcasts (420 multicasts)
... no errors ...
28850266 packets output, 23268567069 bytes, 0 underruns
... no errors ...
Here is a view of the queue maps:
Policed-dscp map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 01 01
1 : 01 01 01 01 01 01 02 02 02 02
2 : 02 02 02 02 03 03 03 03 03 03
3 : 03 03 04 04 04 04 04 04 04 04
4 : 05 05 05 05 05 05 06 05 06 06
5 : 06 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 46 56
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01
2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
Dscp-inputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
4 : 01-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01
5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
6 : 01-01 01-01 01-01 01-01
Cos-outputq-threshold map:
cos: 0 1 2 3 4 5 6 7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
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
Dscp-dscp mutation map:
Default DSCP Mutation Map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63
I have not analyzed QOS to this level before and would like to at least understand what I am seeing.
The drops are happening at times other than when calls are taking place - so it doesn't seem to be relating to queues piling up while waiting to empty the priority queue. The 5-min traffic rate shown above is only about 1.5%. Additionally I had a graphical monitor running at 20 second intervals on that port during the documented period and there were no bursts - traffic level varied less than 1% during that period.
What I think I know is:
The phone is marking the voice traffic dscp 46, and the port trusts -accepts- that marking. If the packet would happen to not be IP, I presume the port would accept the COS, and because of the modified dscp-cos map, it would write the dscp class as 46 and go on using that value for further operations (not sure about that part tho)
All of that at the port level is irrelevant since the drops we're seeing are not on ingress but egress but I wanted to throw it in to make sure I was understanding that end correctly.
On the other end, voice traffic is classified the same way, and trusted through the trunks so that any voice traffic is coming back into the switch and out the user port (in this case 17) with the same markings. This seems to be borne-out by the incomming queue stats - its not shown clearly here since the stats were cleared, stats that include calls show large packet counts on dscp 46 and a smaller number to 45.
ok, so classification seems ok - hopefully. Since it was set up to be simple and straight-forward, the queuing and policing mechanism seems pretty straight-forward. Since priority queue out is specified, voice traffic is dumped into queue 1 (does this wind up being specified as Q02-01 on the queue map?) and that queue is serviced until empty. Even assuming a call is present - which it isn't, this should still be less than 120kbps for a g711 call, leaving plenty of service-capability for data traffic.
So, since no call is present, the remaining data should be handled based on the queue and bandwidth settings. In this case, - and they've been modified a little to try to resolve the issue, theyre set to 10 75 5 10 and since its q1-t1 dropping packets - queue 1: 490 0 0 - it seems I am giving about as much buffer space to the queue being dropped as is possible, correct?
Then the only thing left to consider is the bandwidth allocation for how often that queue gets packets removed from the ring. Doing a show mls qos int que gives
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
At this point - since I am not specifying anything, I'm not sure if it is using shared or shaped. Even if I knew, I'm not sure how to translate it.
If it is shaped. is it 25% bw reserved to service q1, then remaining 75% shared evenly between the remaining 3 queues?
If it is shared, is it saying 'If there are pkts in q1, they can have up to 25% bw, then if pkts in q2, q2 gets up to 25%bw, etc: BUT if Q1 is empty, Q2 gets up to 33% bw? - not sure at all how to read this one...
In any case, even if we presume the queue dropping packets only gets 25% bw, it should still be able to handle up to 20mbps (really 25mbps) with no drops or probs shouldnt it? In which case - why am I seeing drops at only 2% util?
A couple other things: In the case of int fa0/17, I checked the end-users nic configs and verified qos marking on the PC was disabled, and flow control was disabled. Also as I mentioned, he is running 100mbps/full. I chose fa0/17 because the issue seems more severe on this int, than on most of the other ports on this switch.
Also, I am not really getting any user complaints - but that isn't a definite sign that they're not being affected. Also, whereas I have always seen periodic drops with this configuration (minus the modified egress buffer changes made to try to reduce the problem), it seems to have become worse at least on this switch/port in the last 2 weeks with no obvious changes that would account for it.
Finally: In working on all of this, I came across the following statement in a Nortel document that doesn't seem to make sense to me but maybe its my understanding that is faulty:
"
Port based Configuration
Config terminal (Enter global configuration mode)
mls qos (Enable QoS globally)
mls qos map cos-dscp 0 8 16 40 32 46 48 56 (Define ingress CoS-to-DSCP mappings)
Intrerface level
interface GigabitEthernet1/0/1 (Specify the physical port)
switchport access vlan 10 (Native VLAN)
switchport mode access (Set the port to access mode)
switchport voice vlan20 (Voice VLAN)
priority-queue out (Enable the egress exepedite queue)
mls qos trust dscp (Trust IP Phone DSCP Values)
spanning-tree portfast (For Nortel IP Phones)
The Nortel IP Phone marks the voice payload with CoS 6 and DSCP EF when it sends the traffic
to the switch. When the traffic enters the switch port Gi 1/0/1 (in our example), the switch trusts
the CoS value. Then, the switch derives the DSCP value 48 for the CoS value 6 from the
CoS−DSCP default table."
The description accompanying the configuration list seems totally wrong to me. Isn't it that the phone marks with CoS 6 and DSCP EF, then the switch trusts the DSCP value? Is this a typo or do I have a big hole in my understanding? If it is a typo, I really shouldnt need the "mls qos map cos-dscp 0 8 16 24 32 40 46 56" command do I, since the port will automatically trus the dscp and wont need to translate the CoS?
I would really like to thoroughly understand this, and understand why I'm seeing the drops when it seems like there is no reason for them. I've read quite a bit on it but obviously there are still some gaps. Should I modify egress sharing/shaping to try to improve the issue?
I REALLY appreciate anyone who can take the time to straighten me out!
Thanks a lot in advance!!!
k
PS. When I turn off qos the packet drops stop so it certainly seems related to qos
Thanks again!
I am trying to understand the reason for egress packet drops I am seeing on our 3560s.
The switches are wkgrp switches directly connected to users. We use Nortel IP phones with the phone inline with the user PC. PCs auto-neg to 100/full
As a reminder, Nortel phones mark voice traffic dscp 46 and COS 6, sig traffic dscp 40 and cos 5, and data traffic 0/0
The typical port configuration is :
switchport mode access
switchport voice vlan 100
priority-queue out
mls qos trust dscp
spanning-tree portfast
end
Global qos config is:
mls qos map dscp-cos 46 to 6
mls qos map cos-dscp 0 8 16 24 32 40 46 56
mls qos srr-queue input bandwidth 98 2
mls qos srr-queue input buffers 95 5
mls qos srr-queue input priority-queue 2 bandwidth 1
mls qos srr-queue input dscp-map queue 1 threshold 1 40
mls qos queue-set output 2 threshold 1 3100 3100 100 3200
mls qos queue-set output 2 buffers 10 75 5 10
mls qos
What I am seeing is persistent drops from Egress q 1-1
While I know this can happen during bursts, this seems to exceed what I would expect for the low-level usage Im seeing on the interface. Here are stats from 5 mins after doing a clear mls qos int stat
FastEthernet0/17
dscp: incoming
-------------------------------
0 - 4 : 53078 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 29 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 77308 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 29 0 0 0 0
45 - 49 : 0 0 0 549 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 53099 0 0 0 0
5 - 7 : 0 29 0
cos: outgoing
-------------------------------
0 - 4 : 80501 0 0 0 0
5 - 7 : 29 553 0
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 33 0 0
queue 1: 80164 86 615
queue 2: 0 0 0
queue 3: 549 0 260
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 490 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
MainStack2#sh int fa0/17
FastEthernet0/17 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0011.93c1.0713 (bia 0011.93c1.0713)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
...
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
...
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 83286
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 128000 bits/sec, 153 packets/sec
5 minute output rate 1653000 bits/sec, 227 packets/sec
14551956 packets input, 1566102266 bytes, 0 no buffer
Received 9428 broadcasts (420 multicasts)
... no errors ...
28850266 packets output, 23268567069 bytes, 0 underruns
... no errors ...
Here is a view of the queue maps:
Policed-dscp map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 01 01
1 : 01 01 01 01 01 01 02 02 02 02
2 : 02 02 02 02 03 03 03 03 03 03
3 : 03 03 04 04 04 04 04 04 04 04
4 : 05 05 05 05 05 05 06 05 06 06
5 : 06 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 46 56
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01
2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
Dscp-inputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
4 : 01-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01
5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
6 : 01-01 01-01 01-01 01-01
Cos-outputq-threshold map:
cos: 0 1 2 3 4 5 6 7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
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
Dscp-dscp mutation map:
Default DSCP Mutation Map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63
I have not analyzed QOS to this level before and would like to at least understand what I am seeing.
The drops are happening at times other than when calls are taking place - so it doesn't seem to be relating to queues piling up while waiting to empty the priority queue. The 5-min traffic rate shown above is only about 1.5%. Additionally I had a graphical monitor running at 20 second intervals on that port during the documented period and there were no bursts - traffic level varied less than 1% during that period.
What I think I know is:
The phone is marking the voice traffic dscp 46, and the port trusts -accepts- that marking. If the packet would happen to not be IP, I presume the port would accept the COS, and because of the modified dscp-cos map, it would write the dscp class as 46 and go on using that value for further operations (not sure about that part tho)
All of that at the port level is irrelevant since the drops we're seeing are not on ingress but egress but I wanted to throw it in to make sure I was understanding that end correctly.
On the other end, voice traffic is classified the same way, and trusted through the trunks so that any voice traffic is coming back into the switch and out the user port (in this case 17) with the same markings. This seems to be borne-out by the incomming queue stats - its not shown clearly here since the stats were cleared, stats that include calls show large packet counts on dscp 46 and a smaller number to 45.
ok, so classification seems ok - hopefully. Since it was set up to be simple and straight-forward, the queuing and policing mechanism seems pretty straight-forward. Since priority queue out is specified, voice traffic is dumped into queue 1 (does this wind up being specified as Q02-01 on the queue map?) and that queue is serviced until empty. Even assuming a call is present - which it isn't, this should still be less than 120kbps for a g711 call, leaving plenty of service-capability for data traffic.
So, since no call is present, the remaining data should be handled based on the queue and bandwidth settings. In this case, - and they've been modified a little to try to resolve the issue, theyre set to 10 75 5 10 and since its q1-t1 dropping packets - queue 1: 490 0 0 - it seems I am giving about as much buffer space to the queue being dropped as is possible, correct?
Then the only thing left to consider is the bandwidth allocation for how often that queue gets packets removed from the ring. Doing a show mls qos int que gives
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
At this point - since I am not specifying anything, I'm not sure if it is using shared or shaped. Even if I knew, I'm not sure how to translate it.
If it is shaped. is it 25% bw reserved to service q1, then remaining 75% shared evenly between the remaining 3 queues?
If it is shared, is it saying 'If there are pkts in q1, they can have up to 25% bw, then if pkts in q2, q2 gets up to 25%bw, etc: BUT if Q1 is empty, Q2 gets up to 33% bw? - not sure at all how to read this one...
In any case, even if we presume the queue dropping packets only gets 25% bw, it should still be able to handle up to 20mbps (really 25mbps) with no drops or probs shouldnt it? In which case - why am I seeing drops at only 2% util?
A couple other things: In the case of int fa0/17, I checked the end-users nic configs and verified qos marking on the PC was disabled, and flow control was disabled. Also as I mentioned, he is running 100mbps/full. I chose fa0/17 because the issue seems more severe on this int, than on most of the other ports on this switch.
Also, I am not really getting any user complaints - but that isn't a definite sign that they're not being affected. Also, whereas I have always seen periodic drops with this configuration (minus the modified egress buffer changes made to try to reduce the problem), it seems to have become worse at least on this switch/port in the last 2 weeks with no obvious changes that would account for it.
Finally: In working on all of this, I came across the following statement in a Nortel document that doesn't seem to make sense to me but maybe its my understanding that is faulty:
"
Port based Configuration
Config terminal (Enter global configuration mode)
mls qos (Enable QoS globally)
mls qos map cos-dscp 0 8 16 40 32 46 48 56 (Define ingress CoS-to-DSCP mappings)
Intrerface level
interface GigabitEthernet1/0/1 (Specify the physical port)
switchport access vlan 10 (Native VLAN)
switchport mode access (Set the port to access mode)
switchport voice vlan20 (Voice VLAN)
priority-queue out (Enable the egress exepedite queue)
mls qos trust dscp (Trust IP Phone DSCP Values)
spanning-tree portfast (For Nortel IP Phones)
The Nortel IP Phone marks the voice payload with CoS 6 and DSCP EF when it sends the traffic
to the switch. When the traffic enters the switch port Gi 1/0/1 (in our example), the switch trusts
the CoS value. Then, the switch derives the DSCP value 48 for the CoS value 6 from the
CoS−DSCP default table."
The description accompanying the configuration list seems totally wrong to me. Isn't it that the phone marks with CoS 6 and DSCP EF, then the switch trusts the DSCP value? Is this a typo or do I have a big hole in my understanding? If it is a typo, I really shouldnt need the "mls qos map cos-dscp 0 8 16 24 32 40 46 56" command do I, since the port will automatically trus the dscp and wont need to translate the CoS?
I would really like to thoroughly understand this, and understand why I'm seeing the drops when it seems like there is no reason for them. I've read quite a bit on it but obviously there are still some gaps. Should I modify egress sharing/shaping to try to improve the issue?
I REALLY appreciate anyone who can take the time to straighten me out!
Thanks a lot in advance!!!
k
PS. When I turn off qos the packet drops stop so it certainly seems related to qos
Thanks again!