cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
613
Views
0
Helpful
9
Replies

QoS config tips in 6509 (for voice traffic)

jpeterson6
Level 2
Level 2

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

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

9 Replies 9

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

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?

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 . . .

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.

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.

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

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.

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco