QoS config tips in 6509 (for voice traffic)

Answered Question
Mar 11th, 2008

I am searching for some advice to my current QoS needs.

The only traffic that matters in this case is VoiP traffic. Any other traffic is fine at 'default' values. Voice traffic leading into the 6509 is marked as dscp 'EF' and I will be trusting dscp on all relevant ports.

The default egress queueing is set to 1p3q8t, which I imagine would be suitable for my needs (by setting CoS 5 to the priority queue).

The default ingress queueing on IOS 12.2(18)SXF12 is set to 1q8t. Is this acceptable, or should I change it to a queue type that has a priority (ie. 1p1q8t)?

Are there any other recommendations to ensure proper priorities are given for voice traffic?

Thanks,

Jeff

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 8 years 10 months ago

If the voice "server" is a local LAN voice gateway that connects, analog, outside to PSTN, then yes, you're done.

If the voice "server" connects to other voice "servers" across the data network, or the voice "servers" just coordinate VoIP phones directly sending traffic to each other, and if either traffic goes across your WAN edge, then you'll likely need to insure QoS for it too.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joseph W. Doherty Tue, 03/11/2008 - 20:32

Don't forget voice signally. You might need to insure its protection, via QoS, too.

Double check 1p3q8t, both default mappings to queue (CoS and/or DSCP) and whether the 1p is actually active as such.

Usually, ingress queuing is not an issue.

jpeterson6 Wed, 03/12/2008 - 12:21

Thanks for the reply.

Now that you mention the mappings I just realized that for some reason I am unable to change the queueing mode to mode-dscp.

The command 'mls qos queue-mode' doesn't have a 'mode-dscp' option behind it. Am I missing something?

Because of this I am forced to map cos values to my egress queue currently, rather than the desired DSCP values.

Any thoughts on this?

Joseph W. Doherty Wed, 03/12/2008 - 17:56

Sorry, not off the top of my head. I would need to consult the command guides and/or reference. Perhaps someone else will be able to clarify . . .

jpeterson6 Thu, 03/13/2008 - 06:37

Hmm..

In my case would mapping the cos to the queue's be acceptable? The packets are coming in with DSCP 46/EF but that translates to CoS 5, I'm just unsure if it will be read that way.

Joseph W. Doherty Thu, 03/13/2008 - 06:46

If the traffic gets into the queue you need, that's fine, but then the question becomes whether any downstream devices will need to use the marking too. A CoS 5 might not transition beyond the next L3 hop, and likely also be lost if you jump a WAN link.

jpeterson6 Thu, 03/13/2008 - 07:00

Found the problem.. not exactly happy about it.

"This command is supported on 10-Gigabit Ethernet ports only."

I'm running 1Gig fiber blades on my 6509.

Regarding the WAN link- All voip phones are run within a single LAN, will I need to do any QoS configurations on my edge router in this situation?

I'm not too familiar with VoIP itself so I'm unsure of what happens with the traffic when exterior calls are made.

Thanks

Joseph W. Doherty Thu, 03/13/2008 - 09:03

re: WAN

Should only be an issue if VoIP crosses the link. If it's all contained on the LAN, CoS will suffice, but configuration using DSCP would also lend itself to future WAN transfers.

jpeterson6 Thu, 03/13/2008 - 09:08

Just to clarify; As long as QoS works properly on the LAN side (up to the voice servers) with no QoS configured on the edge routers, there won't be any packetloss issues if a voip user makes an external call?

I appreciate all the help you're providing on this issue.

Correct Answer
Joseph W. Doherty Thu, 03/13/2008 - 10:42

If the voice "server" is a local LAN voice gateway that connects, analog, outside to PSTN, then yes, you're done.

If the voice "server" connects to other voice "servers" across the data network, or the voice "servers" just coordinate VoIP phones directly sending traffic to each other, and if either traffic goes across your WAN edge, then you'll likely need to insure QoS for it too.

Actions

This Discussion