when to use policing and shaping

[carl_townshend]

Hi all, Can anyone tell me, when I would want to use polcing and when I would need to use shaping, I cannot see why you would want to drop traffic if you can buffer it instead!

cheers

[Collin Clark]

buffers are only so big

[satish_zanjurne]

Policing:

Traffic policing allows you to control the maximum rate of traffic sent or received on an interface. Traffic

policing is often configured on interfaces at the edge of a network to limit traffic into or out of the

network. Traffic that falls within the rate parameters is sent, whereas traffic that exceeds the parameters

is dropped or sent with a different priority.

Shaping :

Traffic shaping allows you to control the traffic going out an interface in order to match its flow to the

speed of the remote target interface and to ensure that the traffic conforms to policies contracted for it.

Thus, traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby

eliminating bottlenecks in topologies with data-rate mismatches.

The primary reasons you would use traffic shaping are to control access to available bandwidth, to ensure

that traffic conforms to the policies established for it, and to regulate the flow of traffic in order to avoid

congestion that can occur when the sent traffic exceeds the access speed of its remote, target interface.

Configure traffic shaping on an interface if you have a network with differing access rates. Suppose

that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs

at 128 kbps. Sending packets at 256 kbps could cause failure of the applications using the link.

Traffic shaping prevents packet loss. Its use is especially important in Frame Relay networks because

the switch cannot determine which packets take precedence, and therefore which packets should be

dropped when congestion occurs.

See below link for comparison of both..

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

HTH...rate if helpful...

[Joseph W. Doherty]

". . . I cannot see why you would want to drop traffic if you can buffer it instead!"

Just buffering traffic can be counter productive. Dropping traffic is one method to indicate to a traffic flow congestion is forming.

Imagine two hosts each with gig Ethernet that want to copy a 10 gig file from one host to the other. Further imagine, the Ethernet LANs are connected by a 1 Mbps WAN. Do you really want the source side LAN/WAN device to buffer the whole 10 gig file, being received at gig speed, while forwarding it at meg speed?

In other words, intentional dropping can inform the source that it is overdriving the available bandwidth. (BTW, there are other methods to indicate congestion to the source, such as ECN, but dropping is still about the only universal method.)

Beyond the question of dropping vs. buffering, not all equipment offers both, especially in all points of application. Shaping is generally limited to egress, policing can often work ingress or egress.

Suppose we want to limit bandwidth consumption from some external Internet site. I have no control over the source, but I can control what happens on our Internet router. Does is make sense to shape or police on our side?

[carl_townshend]

hi there

thanks for the answer, my next question is, if traffic gets dropped? how does the pc know about this, I gather it would by tcp ack's etc ? what does the pc then do about it ?

[Joseph W. Doherty]

". . . if traffic gets dropped? how does the pc know about this, I gather it would by tcp ack's etc ? what does the pc then do about it ?"

Whether the PC knows about drops is up to both the protocol and the application generating the packets. For example, TCP the protocol will detect drops, TFTP the application will detect drops. Some protocols and applications will not notice the loss (which may, or may not, have an adverse impact to the application).

What the host does about detected drops, is again, up to both the protocol and the application. For those protocols and applications that detect drops, most will resend the dropped packets and might otherwise adjust their behavior. For instance, TCP will reduce its send window or fall back to slow start. Also with regard to dropped packets, both protocols and applications, when resending, will also generally limit themselves to so many resends. If the resend limit is exceeded, they'll give up.

[carl_townshend]

with regards to the policing, Would it drop any traffic over the threshold, or do you have to set what source traffic is allowed through and what should be dropped ?

[Joseph W. Doherty]

Policer can drop traffic over the threshold, or mark the packet differently. (The latter allows deferred treatment of the overspeed packets. They might later be dropped, queued at a lower priority, or passed along without doing anything different against them.)

Policer polices the traffic given to it. It might base this on the source of the traffic (as you ask), but is not limited to just that criteria. You can match the traffic passed to the policier often using an ACL or class-map. What traffic you want to police, is pretty much whatever you want to select. It's also sometimes possible to have different policers working upon the same traffic stream.

[carl_townshend]

hi there, so if I policed certain source traffic, what would happen to the rest of the traffic, would it get passrd as normal?

and if I wanted to police everything, would I just use an acl like permit any any ?

can someone give me an example of the class map for this ?

[Joseph W. Doherty]

"hi there, so if I policed certain source traffic, what would happen to the rest of the traffic, would it get passrd as normal? "

Yes

"and if I wanted to police everything, would I just use an acl like permit any any ?

"

You could

"can someone give me an example of the class map for this ?"

ip access-list extended x

permit tcp host 1.2.3.4 any

class-map match-all x

match access-group name x

policy-map x

class x

police 10000

interface FastEthernet0/0

ip address dhcp

duplex auto

speed auto

service-policy input x

service-policy output x

Router#sh policy-map i

FastEthernet0/0

Service-policy input: x

Class-map: x (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name x

police:

cir 10000 bps, bc 1500 bytes

conformed 0 packets, 0 bytes; actions:

transmit

exceeded 0 packets, 0 bytes; actions:

drop

conformed 0 bps, exceed 0 bps

Class-map: class-default (match-any)

59 packets, 4676 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Service-policy output: x

Class-map: x (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name x

police:

cir 10000 bps, bc 1500 bytes

conformed 0 packets, 0 bytes; actions:

transmit

exceeded 0 packets, 0 bytes; actions:

drop

conformed 0 bps, exceed 0 bps

Class-map: class-default (match-any)

17 packets, 1049 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any