1p1q4t Receive Priority Queue

[eknell]

I have a WS-X6408A-GBIC line-card in my 7609. I am doing QOS on this router, but what is odd to me is that my COS 5 value is not mapped to my Rx strict-priority queue 2?

This does not look normal, but maybe it is?? I have seen other examples with the same queuing structure and COS 5 is mapped to the queue 2. This is what the Rx queuing looks like on one of my Gig interfaces:

Queueing Mode In Rx direction: mode-cos

Receive queues [type = 1p1q4t]:

Queue Id Scheduling Num of thresholds

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

1 Standard 4

2 Priority 1

queue tail-drop-thresholds

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

1 100[1] 100[2] 100[3] 100[4]

queue thresh cos-map

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

1 1 0 1 2 3 4 5 6 7

1 2

1 3

1 4

2 1

Packets dropped on Receive:

BPDU packets: 0

queue thresh dropped [cos-map]

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

1 1 0 [0 1 2 3 4 5 6 7 ]

* - shared receive counter

As you can see, COS values all mapped to Rx queue 1. I appreciate your help!

Thanks,

Ethan

[Edison Ortiz]

According to the documentation:

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1015635

It's default behavior. You can manually change it to Queue 2.

___

Edison.

[eknell]

Edison,

I have actually tried that, "priority-queue cos-map 1 5" and it does nothing. It says something like propagating to all interfaces, but when I look at the queuing on the interface, nothing changes?

Do you happen to know how to manually change it to Q2?

Thanks again..

[Edison Ortiz]

The link I posted also indicates the Queue will always be 1.

I don't have an equipment at the moment for testing, if you wish - you can open a TAC case.

I also want to point out, you should concentrate on egress priority queueing to be functioning as ingress priority queueing does not provide as much benefit.

__

Edison.

[eknell]

Edison,

I appreciate it, but all of my egress queuing is configured correctly, which why I am interested in the ingress portion. It seems to be a QOS issue and am just double checking everything, ya know?

Let me ask you this. Have you ever heard RTP packet reordering across a 2 Gig Etherchannel before? Maybe something like Interleaved packets causing VoIP issues??

I don't even know if this could be a cause for our VoIP issue, I am just having to start to look at other things besides QOS that could cause quality issues.

Thanks for you responses!

[Edison Ortiz]

Let me ask you this. Have you ever heard RTP packet reordering across a 2 Gig Etherchannel before?

Not on EtherChannel as the traffic is per flow - in other words - you won't have RTP traffic equally balanced hence no reordering on the inter-switch link.

Maybe something like Interleaved packets causing VoIP issues??

Interleaving is tied to MLPPP, no issue with Giga EtherChannel.

___

Edison.

[eknell]

Thanks again!

By the way, I had already opened a TAC case a couple weeks ago on this issue. They went through all my QOS configurations with a fine tooth comb, across every router and switch hop and they said everything was provisioned correctly, which is why I am trying to think "outside the box".

I am dealing with calls that traverse 3 PBX's, 2 being VoIP PBX's with the last VoIP PBX SIP trunking to the 3rd Class5 Phone switch, across our fiber backbone with multiple router and switch hops?!

You can see I have so many variables in the mix, and it is like trying to find a needle in a hay stack!

Anyhow, I will quit rambling. Again, I appreciate your help! Have a good one!

[Edison Ortiz]

IP SLA can be your friend in situations such as the one you are experiencing:

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html