Wednesday, 25 February 2009

Rate Limit and QoS

One of the biggest problems with WAN links to how to manage your traffic, should it be percentage based or rate limited?

Well percentage based is fine to a point, that is to say its fine but in a IP calls it could be a problem and some other real time services such a video.

Quick example 50% of your WAN link is reserved for IP calls by you QoS policy lets say... but if more than x number of users make a call the link will have too much traffic and calls will become fuzz to say the least.
So to over come this we are going to just allow 15 on our 1158kbps line with no more than 100kbps on each.

The following example shows a T1 (1536 kbps) link configured to permit RSVP reservation of up to 1158 kbps, but no more than 100 kbps for any given flow on interface serial 0/0. Fair queuing is configured with 15 queues to support those reserved flows, should they be required.

interface serial0/0
fair-queue 64 256 15
ip rsvp bandwidth 1158 100


Another way this can be done is between a host or range so that the quolity remains high for the links between

To enable a router to simulate receiving and forwarding Resource Reservation Protocol (RSVP) RESV messages, use the ip rsvp reservation global configuration command. To disable this feature, use the no form of this command.
ip rsvp reservation session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-dport
sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth
burst-size

The following example specifies the use of a Shared Explicit style of reservation and the controlled load service, with token buckets of 100 or 150 kbps and 60 or 65 kbps maximum queue depth:
ip rsvp reservation 224.250.0.2 172.16.1.1 UDP 20 30 172.16.4.1 Et1 se load 100 60
ip rsvp reservation 224.250.0.2 172.16.2.1 TCP 20 30 172.16.4.1 Et1 se load 150 65


The following example specifies the use of a Wild Card Filter style of reservation and the guaranteed bit rate service, with token buckets of 300 or 350 kbps and 60 or 65 kbps maximum queue depth:
ip rsvp reservation 224.250.0.3 0.0.0.0 UDP 20 0 172.16.4.1 Et1 wf rate 300 60
ip rsvp reservation 226.0.0.1 0.0.0.0 UDP 20 0 172.16.4.1 Et1 wf rate 350 65


Note that the Wild Card Filter does not admit the specification of the sender; it accepts all senders. This action is denoted by setting the source address and port to zero. If, in any filter style, the destination port is specified to be zero, RSVP does not permit the source port to be anything else; it understands that such protocols do not use ports or that the specification applies to all ports. This can can be a problem if other services are on the same range so best to define access lists to block all unwanted traffic.

Last but not least.
To reserve a strict priority queue for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the ip rtp priority interface configuration command. To disable the strict priority queue, use the no form of this command.
ip rtp priority starting-rtp-port-number port-number-range bandwidth


The following example first defines a CBWFQ configuration and then reserves a strict priority queue
with the following values: a starting RTP port number of 16384, a range of 16383 UDP ports, and a
maximum bandwidth of 40 kbps:

! The following commands define a class map:
class-map class1
match access-group 101
exit

! The following commands create and attach a policy map:
policy-map policy1
class class1
bandwidth 3000
queue-limit 30
random-detect
random-detect precedence 0 32 256 100
exit

interface Serial1
service-policy output policy1
! The following command reserves a strict priority queue:
ip rtp priority 16384 16383 40


Defining what is best for you or even using all of these rate limits and QoS is something that will be up to you... but remember not to use too many of them as other wise you will end up with a lines that are never fully used as all the policy's prevent it.

Good rule of thumb keep the policy's simple.

No comments: