Hi,
(i) Based on what you're trying to achieve, your policy doesn't make too much
sense.
You say that the bottleneck is your upstream bw of 3Mbps, but still you shape
the traffic to 48Mbps.
(ii) It's essential to know what type of link the policy will be attached to.
Physical link-speed should always be considered in QoS engineering due to
serialization delay-variation between different ifaces. I assume now that you
have a FE link towards a cable-modem.
(iii) Just to clarify. If there's no congestion on the link, there's no way for
packets to get prioritized.
Think of it as the queue to a cashier at your grocerystore. If theres no line
at all, you'll just pay and go through, regardless of your personal status.
It's the same logic behing LLQ. The priority queue/LLQ only activates when
prioritized frames enters an already congested tx-queue.
Since I assume that you have a FE link towards a modem, I would go for a
hierachial policy to shape all traffic regardless of class, then have an
underlying policy where you prioritize the VoIP class.
My suggestion:
policy-map LLQ
class QOS_REAL-TIME_VOIP
priority
police 2500000 conform-action transmit exceed-action drop
policy-map PARENT-SHAPER
class class-default
shape average 3000000
service-policy LLQ
interface FastEthernetX
service-policy output PARENT-SHAPER
Notice that policer is present to prevent VoIP class from starving the whole
bandwidth. But if you don't care about this you could just skip it.
Good luck!
Regards,
Arash
> Date: Wed, 20 Nov 2013 10:08:49 -0800
> From: [email protected]
> To: [email protected]
> Subject: [c-nsp] QoS for VoIP - clarification needed in non-congested times
>
>
>
> Hello,
>
>
> I need a little clarification / assistance please. I
> have a cable modem connection that is 50mb down and 3mb up. The most I
> ever do in the download direction is around 8 to 10 mb. It's the upload
> that gets me sometimes when it spikes to around 2.5mbps up. I need to
> make sure my voip traffic ALWAYS gets sent on the wire first, regardless if
> there is congestion or not. Would the policy below work? If not, how should I
> tweak it.
>
> Thank you,
>
> class-map match-any QOS_REAL-TIME_VOIP
> match access-group name VOIP_Traffic
>
> ip access-list extended VOIP_Traffic
> permit ip any any eq x.x.x.x
>
> permit ip any any eq x.x.x.x
>
>
> policy-map VoIP
>
> class QOS_REAL-TIME_VOIP
> priority 784
> class class-default
> shape average 48000000
> bandwidth 50000000
> Thank you,
>
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
