05-28-2003 08:27 AM - edited 03-02-2019 07:42 AM
I have a branch office connected to a main office over a 128K frame-relay connection. The branch office runs a mission critical application that requires only 28K of bandwidth to run normally. When a user at the branch office checks email, the mission critical application slows down.
How can I prioritize the traffic so my mission critical application is not effected by other non-important traffic? I want the mission critical application to always have 28K of bandwidth available regardless of what the user is trying to download.
Any help is very much appreciated! Thank you.
05-28-2003 08:38 AM
My advive will be to use Committed Access Rate (Rate limit) to limit every other type of traffic to 100K, leaving the remaining 28K free for the mission critical application.
05-28-2003 10:00 AM
Thanks for the push in the right direction. Do you have any quick help guides or configuration samples? I'm looking on my own, but it seems confusing unless you understand exactly what you are looking at.
05-28-2003 10:26 AM
Try this
Create access list to permit all traffic and deny the mission critical traffic, assume mission critical traffic is to server 10.10.10.10 from network 192.168.1.0
access-list 100 ip deny 192.168.1.0 0.0.0.255 host 10.10.10.10
access-list 100 ip permit any any
Then create rate limit access group command at the interface using the access list to limit it to 100k (at the interface configuration level)
rate-limit input access-group 100 100000 12500 12500 conform-action transmit exceed-action drop
rate-limit output access-group 100 100000 12500 12500 conform-action transmit exceed-action drop
try something like this and see what happens
Could check the following link also
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/qcfcar.htm
05-29-2003 04:56 AM
Be careful with your solution, because it may not be sufficient to simply restrict competing traffic to 128 minus 28 kbps. If your mission critical traffic is delay sensitive (and from what you describe, it is, the only question is just how sensitive), than it may not be able to tolerate having its packets delayed by the time required to transmit the background packet in progress at the time of the arrival of the critical packet at the router. Cisco routers do not support preemption of a lower priority packet while it is being transmitted. Worst case, each critical packet could be delayed by 95ms, almost 200ms round trip (assuming an MTU of 1500 bytes).
If this turns out to be the case for your application, you will also need to apply the link level fragmentation tricks used to support real-time VOIP on slower links shared with data traffic.
Good luck and have fun!
Vincent C Jones
06-12-2003 02:53 AM
I have been thinking much about this, and I think that Vincent is right. But, how do you implement what you suggest?
06-12-2003 06:05 AM
Everyone, I got some outside help with building a configuration. It seems to work with mixed results. I have included the key portions of the config below:
Please, anyone who can comment on the config, your opinion is very welcome!
class-map match-any SCALE
match access-group 199
!
!
policy-map SCALE
class SCALE
priority 28
class class-default
fair-queue
random-detect
!
frame-relay de-list 1 protocol ip list 198
interface Serial0.1 point-to-point
description primary PVC to Jersey City
ip address 172.24.200.22 255.255.255.252
no arp frame-relay
no cdp enable
frame-relay de-group 1 31
frame-relay interface-dlci 31
class SCALE
map-class frame-relay 128k
no frame-relay adaptive-shaping
frame-relay cir 128000
frame-relay mincir 128000
!
map-class frame-relay SCALE
frame-relay adaptive-shaping becn
frame-relay cir 128000
frame-relay mincir 128000
service-policy output SCALE
access-list 198 deny ip host 172.24.24.29 host 172.24.0.10
access-list 198 permit ip any any
access-list 199 permit ip host 172.24.24.29 host 172.24.0.10
06-12-2003 10:55 AM
I noticed in your map-class frame-relay SCALE
frame-relay adaptive-shaping becn
frame-relay cir 128000
frame-relay mincir 128000
service-policy output SCALE
you have both you cir and you mincir set to 128000 if you circuit is a 128k CIR on a 256k circuit set your cir to 256000 and add frame-relay bc 32000
another option for setting up queues would be CBWFQ you could set a percentage of the circuits bandwidth 1% 10% what ever you choose and the traffic from your access list 199 would be guaranteed that much bandwidth during congestion
06-13-2003 05:54 AM
I've only been at this position for 3 months, I just noticed most of our ports are 512K, CIR 128K. I will adjust accordingly. I'm not a router expert, but is CBWFQ supported on 1720 series routers-- I'll check into it and test.
CAR is definitely not supported on the 1720 & 1721's, which was my first configuration attempt using 1751's and higher in the test lab.
06-12-2003 10:47 PM
Why to go for something complex if you can achieve your goal with a simple config? Everything you need is the plain priority queueing - it will guarantee 28Kbps for your mission-critical traffic regardless of anything else.
interface XX
priority-group 1
!
priority-list 1 protocol ip high list 101
priority-list 1 default normal
!
access-list 101 ............your traffic............
Configure this on both ends of the line and watch how it behaves. You may want to adjust the size of the queues. Only IF you are not satisfied with this solution, go for something more complex. I advise you NOT to use CAR, as suggested earlier - it drops packets instead of delaying them.
06-12-2003 10:59 PM
...I based my previous advice on assumption that your mission-critical application requires (and consumes) approx. 28K of the bandwidth. There is a danger, however, that all capacity of your link will be occupied by it. If you see this happening, you may want to go for the other solution.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: