Rate-Limit command and Normal_burst in spesific case

[Kanan Huseynli]

Hi there,

We have 2911 router in one of our branches with 3 interfaces (g0/0-1-2).

G0/0 is (private) WAN port with max 10Mbps link from ISP.

G0/1 is LAN port with sub-interfaces for some vlans of switch attached to this port.

Gi0/2 is "Security" port where cameras exist.

Due to high video transmission,usually G0/0 (WAN) link utilization approximately 9-9.5Mbps (~95%). I want to implement rate-limit on G0/2 input -to which port traffic comes.I am interested in calculating normal burst for configuration rate-limit command (as it requires this value with max_burst).

Cisco recommends normal_burst=CIR(in bits)*1.5/8 (result in bytes).Actually,I did it ,it seems everything is normal.But I have seen in some forums/blogs that this formula of normal_burst is just one of calculations.There are some other formulas depending on situation.

In short,I want to limit rate to 2 Mbps for input of G0/2,but I dont know how to choose appropriate burst value exactly for this situation.Keep in mind that link utilization is almost there.Even when I today(during working hours) looked at output of show interfaces summary command ,it shows over 1200 pakets per second come to G0/2 port.

Could anyone help me in choosing this value?

Thanks in advance,

Kanan Huseynli CCNA,CCNP Route,CCNP Switch

[Joseph W. Doherty · Accepted solution]

I would suggest, instead of policing, implement queuing (on the WAN interface), providing the security camera traffic low priority but large queues.  Ideally, this will keep security camera traffic from being adverse to your other traffic, while also avoiding dropping security camera traffic.

e.g.

policy-map sample
 class camera
  bandwidth percent 1
  queue-length 1024
 class class-default
  bandwidth percent 99
  fair-queue

int g0/0
 !speed 10? - if not, you would need a parent shaper, but running interface at CIR will work better
 service-policy output sample

[Kanan Huseynli]

Thanks for you attention on my topic..

Actually,given task is limiting bandwidth for Security traffic.I did quick search and found that rate-limit is right command (at least,it seems). And this command requires not only bps value but also normal burst value.It is interesting normal burst for my situation.

Now,come back to your answer.I have recently begun to read about QoS,so I can not catch exact points in your answer,unfortunately(

So,my questions regarding to your answer:

What does "giving low priority to camera traffic" mean in your configuration? Does configuring low bandwidth make it less preferable?

What is actual queue length,so we give 1024 for this specific traffic?

P.S Yes,speed between branch router and ISP is 10Mbps (100 is more expensive)

Regards,

[Joseph W. Doherty]

What does "giving low priority to camera traffic" mean in your configuration? Does configuring low bandwidth make it less preferable?

In the sample I provided, if non-camera and camera traffic want bandwidth at the same time it will be divided in the ratio of 99:1 which means non-camera traffic is likely to be transmitted before camera traffic.

What is actual queue length,so we give 1024 for this specific traffic?

Unsure what you're asking.  Default queue lengths vary, often it's 64 packets.  1024 is the maximum number of packets allowed to queue.  Many interfaces support a maximum queue length of 4096.  As I'm assuming security video is doesn't require real-time, it can be delayed.  However, we want to avoid drops as that will interrupt the video picture.  1024, might be larger than need, or not enough.

P.S Yes,speed between branch router and ISP is 10Mbps (100 is more expensive)

It's physically running at 10 Mbps, not logically limited to 10 Mbps, correct?

[Kanan Huseynli]

Thanks for your support,now everything related to your config is clear.I will try it.

Now,could you provide normal burst value when rate-limit is selected to be 2 000 000 (2Mbps) ?

Thanks,

P.S ISP side limits traffic to 10Mbps...Physically,Router's Gig port connected to media-convertor to which fiber link from ISP is attached.

[Joseph W. Doherty]

P.S ISP side limits traffic to 10Mbps...Physically,Router's Gig port connected to media-convertor to which fiber link from ISP is attached.

Let me re-phrase, what bandwidth is g0/0 running at?  If not 10 Mbps, for queuing to be effective, you'll need to shape.

If you do need to shape, a shaper with FQ, alone, might also solve your problems.

Now,could you provide normal burst value when rate-limit is selected to be 2 000 000 (2Mbps) ?

That depends on the nature or your traffic and what you're trying to accomplish.  In your case, you might just try the Cisco defaults.  As you also noted in your OP, "There are some other formulas depending on situation."  However, I've rarely found any fixed formula deal well with real-world situations.

Video traffic is often very variable in bandwidth demand over a short interval, so a small Bc will likely drop packets, precluding it being adverse to your other traffic.  But dropping video packets can be very detrimental to the video stream.  Often only a few drops makes the whole stream worthless.  With a policer, to preclude video drops, you'll want a large BC, but then a video burst may be detrimental to your other traffic.

Again, likely your best solution is queuing priorities.

BTW, with some video streams, the receiver will inform the sender packets are being lost and the sender will then send the same video with less quality but also using less bandwidth.  I doubt your video supports that.

[Kanan Huseynli]

Our physical interface is 1Gig.I have seen that it is auto-negotiated to 100Mbps (between ISP and router interface there is media-convertor.As I understand,router auto-negotiated with convertor). I dont know ISP side,but senior network admin said that ISP gives at most 10Mbps.

I have been monitoring show interfaces summary,and output drops on Tunnel interface (Which is towards to HQ) incremented by 1 per 30-60minutes.It seems ,everything is OK.

Anyway,in case of any "bad report" I will try to implement queuing  instead of policing.

Thanks for all your support.

Regards,