Please see the updated configuation i have modified it but still not able to restrict the user,

Building configuration...

*May 29 15:25:44.768: %SYS-5-CONFIG_I: Configured from console by console

Current configuration : 1247 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Router-C

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

!

resource policy

!

ip subnet-zero

!

!

ip cef

no ip dhcp use vrf connected

!

ip dhcp pool users

network 10.1.4.0 255.255.255.0

default-router 10.1.4.1

!

!

!

!

voice-card 0

no dspfarm

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

class-map match-all testclass2

match access-group 160

class-map match-all testclass

match access-group 150

!

!

policy-map testpolicy

class testclass

priority 8

class testclass2

priority 5990

class class-default

fair-queue

!

!

!

!

!

!

interface FastEthernet0/0

ip address 10.1.3.1 255.255.255.0

duplex auto

speed auto

service-policy output testpolicy

!

interface FastEthernet0/1

ip address 10.1.4.1 255.255.255.0

duplex auto

speed auto

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.3.2

!

!

ip http server

no ip http secure-server

ip nat inside source list 100 interface FastEthernet0/0 overload

!

access-list 150 permit ip host 10.1.4.3 any

access-list 160 permit ip host 10.1.4.5 any

!

!

!

!

control-plane

!

!

!

!

!

!

!

!

!

!

line con 0

line aux 0

line vty 0 4

login

!

scheduler allocate 20000 1000

!

end

Router-C#

Router-C#sh run

Building configuration...

Current configuration : 1247 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Router-C

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

!

resource policy

!

ip subnet-zero

!

!

ip cef

no ip dhcp use vrf connected

!

ip dhcp pool users

network 10.1.4.0 255.255.255.0

default-router 10.1.4.1

!

!

!

!

voice-card 0

no dspfarm

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

class-map match-all testclass2

match access-group 160

class-map match-all testclass

match access-group 150

!

!

policy-map testpolicy

class testclass

priority 8

class testclass2

priority 5990

class class-default

fair-queue

!

!

!

!

!

!

interface FastEthernet0/0

ip address 10.1.3.1 255.255.255.0

duplex auto

speed auto

service-policy output testpolicy

!

interface FastEthernet0/1

ip address 10.1.4.1 255.255.255.0

duplex auto

speed auto

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.3.2

!

!

ip http server

no ip http secure-server

ip nat inside source list 100 interface FastEthernet0/0 overload

!

access-list 150 permit ip host 10.1.4.3 any

access-list 160 permit ip host 10.1.4.5 any

!

!

!

!

control-plane

!

!

!

!

!

!

!

!

!

!

line con 0

line aux 0

line vty 0 4

login

!

scheduler allocate 20000 1000

!

end

I m trying to restrict the user to bandwidth 74990 but still failling user is able to download in MB

can anyone help me out

Recently I stumbled across Cisco LLQ documentation that the implicit policer only rate limits when there's interface congestion. The simple solution would be to add a police statement within the LLQ class so the class will never exceed its allocated bandwidth regardless of whether other traffic causes interface congestion. Something like:

policy-map testpolicy

class testclass

priority 8

police 8000

class testclass2

priority 74990

police 74990000

Hi Wasiim,

As said by Joseph, please remember that QoS queuing policies(not even LLQ) never kicks in if you don't have congestion. If your bandwidth utilization is low, then never expect any participation of QoS.

Regards...

-Ashok.

Hi,

Totally agree with Joseph and Ashok. The action of policing with LLQ depends upon if there is congestion > Policing will only be done if congestion occurs - with no congestion if the bandwidth required is more than the priority it won't be policed - but the extra packets will not be moved from the tail to the head of the queue (prioritized) like the conforming bandwidth, meaning that only the conforming bandwidth is prioritized and moved from the tail to the head of queue regardless there is congestion or not - implying that the prioritization is what is always policed and not the packet flow.

BR,

Mohammed Mahmoud.

thanks for the useful information. few more questions, I will have 6 MB bandwidth on my internet rotuer, I want that only specific traffic of video conferenceing server always get 386 KBps bandwidth.

will that above mention configuration will in live enviroment.

I have vsat link, which is terminate on Gigabit ethernet interface, is there any need to change the bandwidth on physical interface which is 1000 Mbps to actually bandwidth of 6 MB or leave it as it is

Hi wasim,

Changing the bandwidth command will not change the actual bandwidth that ISP has provided.It's hard to make the gigabit interface to get congestion. If you want to restrict the bandwidth all the time then policing is good way to go. Joseph provided a good one.

HTH

Thot

If you want to provide a minimum guarantee of bandwidth for some traffic, that can be accomplished by the bandwidth statement within a CBWFQ's class. If you want to limit the bandwidth within the CBWFQ class, then you want to shape or police it.

Whether or not to manage your gig interface that you know will be reduced to 6 Mbps depends on whether you expect traffic above 6 Mbps to create quality issues and whether you can manage such a situation better. (Usually I find the answer is yes to both questions. In your case, you might benefit from something as simple as a 6 Mbps shaper on the gig interface leading to the vsat link.)

Thanks for the reply, you mean to say there is no need to change anything on gig interface.

I have to make the policy and reserve the bandwidth and apply that policy on the gig interface. nothing to change not even bandwidth on the interface.

class-map match-all testclass2

match access-group 160

!

class testclass2

priority 386

class class-default

fair-queue

interface gig0/0

ip address 10.1.3.1 255.255.255.0

duplex auto

speed auto

service-policy output testpolicy

access-list 160 permit ip host 10.1.4.5 any

will that confiugration give 368 BW to this source in any case, and rest of the traffic treated as normal.

I will just apply this policy on interface nothing else is required on interface.

No, if you're going to apply any policy at all, and you know the bandwidth is constricted downstream, then you should shape for that restriction.

e.g.

(Something like)

class-map match-all testclass2

match access-group 160

!

policy-map testpolicy

class testclass2

priority 386

class class-default

fair-queue

policy-map vsat-shaper

class class-default

shape 6000000

service-policy testpolicy

interface gig0/0

ip address 10.1.3.1 255.255.255.0

duplex auto

speed auto

service-policy output vsat-shaper

access-list 160 permit ip host 10.1.4.5 any

The above will guarantee your host at 10.1.4.5 with at least 368 Kbps of bandwidth, with priority queueing. All other traffic will FQ all other available bandwidth, up to 6 Mbps.

If u see above I have applied the service policy on interface gig 0/0.