[nsp] QoS with CBWFQ within GTS

[khiz]

Hie
No  i have been trying to configure LLQ
i have 2 VPN service policies child1-vpn and child2-vpn which  i want to shape individually . within each of these child polcies i hv various classes that have been guaranteed bandwidth using CBWFQ ..

ThaNks
K 

Hi Gurus,
i have been trying to configure CBWFQ  within GTS as follows. as per the cisco docs

policy-map child1-policy
class child1
bandwidth 256

policy-map child2-policy
class child2
bandwidth 256

The remaining 2 in global config mode ... empty class
class child1-vpn
class child2-vpn

policy-map parent-policy
class  child1-vpn
shape average 25600
service-policy child1-policy

class  child2-vpn
shape average 25600
service-policy child2-policy


The problem is that after i applied the parent-policy in the interface . there are no matches .. all traffic seems to fall in class-default

however individually applying the child policies child1-vpn or child2-vpn shows matches

ALso after applying any of the child policies as a service-policy within the default-class of the parent-policy shows matches 






On Tue, 20 Jul 2004 Saku Ytti wrote :
>On (2004-07-20 17:00 -0000), khiz   wrote:
>
> > i have been trying to configure CBWFQ  within GTS as follows. as per the cisco docs
>
>You didn't spesify what you want to do, but I assume you want to sell f.ex.
>subrate ethernet and still protect ie. VoIP. Try something like this:
>
>class-map match-any LLQ
>   match <criteria>
>
>polcy-map 256k
>   class class-default
>     shape avarage 25600
>     service-policy priority
>
>policy-map priority
>   class LLQ
>     priority percent 40
>   class class-default
>     fair-queue
>     random-detect
>
>interface PIM
>   service-policy output 256k
>
>
>  First you define parent which does nothing else but shapes the speed
>and calls sub/child policy for all and every packet. Then use subpolicy
>normally. If you're using serial or ATM remember to adjust tx-ring
>accordingly, so that you can serialize tx-ring full of bulk traffic in worst
>case scenario without unacceptable delay to priority traffic.
>
>Hope this helps,
>--
>   ++ytti
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/