07-25-2022 12:20 AM
Dear All,
I have a requirement to limit Youtube bandwidth for LAN users in ISR 4000 series, I am thinking of below configution, can some one please correct me if there is a better way to do this or recommendation.
ISP > Uplink download/upload speed is 500mbps
LAN > limit youtube 20mbps and allow remaining bandwidth
ip access-list extended URL-Filter-ACL
deny ip any host 1.2.3.4
permit ip any any
class-map match-any youtube
match protocol youtube
policy-map LYouTube
class youtube
police cir 20000000 (limit youtube bandwidth to 20mbps)
conform-action transmit
exceed-action drop
class class-default
police cir 500000000
interface GigabitEthernet0/0/0 > LAN
no ip address
negotiation auto
interface GigabitEthernet0/0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
no ip redirects
no ip unreachables
ip nat inside
ip access-group URL-Filter-ACL in >>> to block ip 1.2.3.4
ip nbar protocol-discovery
service-policy output LYouTube
interface GigabitEthernet0/0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
no ip redirects
no ip unreachables
ip nat inside
ip access-group URL-Filter-ACL in >>> to block ip 1.2.3.4
ip nbar protocol-discovery
service-policy output LYouTube
Solved! Go to Solution.
07-25-2022 08:33 AM - last edited on 07-28-2022 11:01 PM by Translator
Is the 20 Mbps limit per VLAN or for all VLANs?
BTW, if your policy has both a 20 Mbps and 500 Mbps limits, i.e. overall that's 520 Mbps, which may not be what you intend. Normally, you would limit your overall traffic to 500 Mbps, and within the 500 Mbps, sub-limit certain traffic type(s). (See @paul driver's posting - similar might be applied to interface feeding LAN.) Also, as you have two subinterfaces with policy applied, your overall limits are also 2x. (Also BTW, if ISP's down limit is 500 Mbps, you shouldn't need to try to further limit to 500 Mbps in your policy.)
Another BTW, if doing
ip nbar protocol-discovery
so you can match using a NBAR protocol, the prior shouldn't be needed. It's used for further traffic analysis (well that's how it used to work - unknown whether still true).
Yet other BTWs, when doing downstream rate control of non-TCP traffic, bandwidth usage before your control point might not adjust its transmission rate when packets are dropped.
Setting a hard cap on something like Youtube traffic, when encountered, might be (very) adverse to all active Youtube flows.
Although @Georg Pauwen is correct that shaping is often "better" than policing, as it buffers/queues excess rather than immediately discard it, it too will still discard when there's consistent/long-term oversubscription. If there is, policing would "trigger" sooner, which may (or may not) get YouTube streams to slow sooner too. Difficult to say which would be better in your case beyond saying, if current average YouTube is 20 Mbps or less, shaper likely would be better, but average is higher than 20 Mbps, especially if a lot higher, policing might actually be better.
07-25-2022 03:26 PM - last edited on 07-28-2022 11:04 PM by Translator
Hello
Apologies I just noticed the interface you are applying the policer is the lan interfce, as such the policer I would say should be applied ingress preferably on the parent physcial interface to incorpate both sub-interfaces and then append the Hqos shape policy in the wan interface.
int gig0/0/0
service-policy input LYouTube
policy-map QOS-CHILD
class youtube
bandwitdh 20000
fair-queue
class class-default
fair-queue
policy-map QOS-PARENT
class class-default
shape average 500000000
service-policy QOS-CHILD
int x/x
Description WAN link
service-policy output QOS-PARENT
07-25-2022 12:56 AM
Hello,
the config looks good as far as I can tell. The only thing: shaping is usually better than policing, so you might want to shape, as policing just cuts off traffic when the limit is exceeded, whereas shaping smoothes out traffic.
07-25-2022 01:07 AM - last edited on 07-28-2022 10:59 PM by Translator
Hello
You could also give some fairness to the rest of your traffic
policy-map QOS-CHILD
class youtube
police cir 20000000 conform-action transmit exceed-action drop
class class-default
fair-queue
policy-map QOS-PARENT
class class-default
shape average <cdr of wan link bps)
service-policy QOS-CHILD
int x/x
Description WAN link
service-policy output QOS-PARENT
07-25-2022 08:33 AM - last edited on 07-28-2022 11:01 PM by Translator
Is the 20 Mbps limit per VLAN or for all VLANs?
BTW, if your policy has both a 20 Mbps and 500 Mbps limits, i.e. overall that's 520 Mbps, which may not be what you intend. Normally, you would limit your overall traffic to 500 Mbps, and within the 500 Mbps, sub-limit certain traffic type(s). (See @paul driver's posting - similar might be applied to interface feeding LAN.) Also, as you have two subinterfaces with policy applied, your overall limits are also 2x. (Also BTW, if ISP's down limit is 500 Mbps, you shouldn't need to try to further limit to 500 Mbps in your policy.)
Another BTW, if doing
ip nbar protocol-discovery
so you can match using a NBAR protocol, the prior shouldn't be needed. It's used for further traffic analysis (well that's how it used to work - unknown whether still true).
Yet other BTWs, when doing downstream rate control of non-TCP traffic, bandwidth usage before your control point might not adjust its transmission rate when packets are dropped.
Setting a hard cap on something like Youtube traffic, when encountered, might be (very) adverse to all active Youtube flows.
Although @Georg Pauwen is correct that shaping is often "better" than policing, as it buffers/queues excess rather than immediately discard it, it too will still discard when there's consistent/long-term oversubscription. If there is, policing would "trigger" sooner, which may (or may not) get YouTube streams to slow sooner too. Difficult to say which would be better in your case beyond saying, if current average YouTube is 20 Mbps or less, shaper likely would be better, but average is higher than 20 Mbps, especially if a lot higher, policing might actually be better.
07-25-2022 10:19 AM - last edited on 07-28-2022 11:02 PM by Translator
Hi @Georg Pauwen @paul driver @Joseph W. Doherty appreciate this valuable information, It is better if I can limit overall bandwidth for 20mbps for YouTube and the remaining 480mbps for other traffic.
in that way, how can I limit 20mbps youtube bandwidth for two lan subinterfce in common(not individually).
@paul driver I am getting below error when I applying fairque
(config-pmap-c)#fair-queue
CBWFQ: Not supported on subinterfaces and efps
07-25-2022 10:36 AM
"It is better if I can limit overall bandwidth for 20mbps for YouTube and the remaining 480mbps for other traffic."
Sure, makes sense to limit YouTube traffic, but no need to further limit your other traffic. I.e. other traffic will obtain anywhere from 480 Mbps to 500 Mbps (the latter, 500, assuming that's all your provide will allow).
"in that way, how can I limit 20mbps youtube bandwidth for two lan subinterfce in common(not individually)."
I think (?) that might be accomplished by placing just one (egress/out) policy on the parent/main interface. If that doesn't work, than it might be accomplished by placing a policy (ingress/in) on your provider's connected interface. (Note, the latter could only police, not shape, as shapers can only be used on egress policies.)
07-25-2022 11:01 AM
Thanks @Joseph W. Doherty , if I have three sub interface, two sub interface need 20mbps youtube(common) and one sub interface need 30mbps youtube.
remaining bandwidth for other traffic 450mbps( 500-(20+30)), sorry to ask for many combinations.
07-25-2022 01:23 PM
Hmm, unsure you can limit two subinterfaces to a combine aggregate while having a third interface with its own limit. (You can, of course, have 3 "independent" limits, i.e. one on each subinterface, but that would be 20+20+30, not 20(for two interfaces, combined)+30. Again, remaining bandwidth shouldn't need to be controlled, as it will be, just that, i.e. "remaining".)
Possibly (?), if you set a policy on the main interface, and match against the IPs for used downstream for two subinterfaces, whose aggregate is to be limited to 20 Mbps, might work.
07-25-2022 03:26 PM - last edited on 07-28-2022 11:04 PM by Translator
Hello
Apologies I just noticed the interface you are applying the policer is the lan interfce, as such the policer I would say should be applied ingress preferably on the parent physcial interface to incorpate both sub-interfaces and then append the Hqos shape policy in the wan interface.
int gig0/0/0
service-policy input LYouTube
policy-map QOS-CHILD
class youtube
bandwitdh 20000
fair-queue
class class-default
fair-queue
policy-map QOS-PARENT
class class-default
shape average 500000000
service-policy QOS-CHILD
int x/x
Description WAN link
service-policy output QOS-PARENT
07-28-2022 03:01 PM
BTW, since @paul driver has both LAN and WAN policies applied for traffic flowing to Youtube, you'll probably, more likely, want to control traffic, for traffic flowing from Youtube.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide