Traffic-Shape or Policy-Map

Unanswered Question
Nov 25th, 2008

Hi Experts! I am trying to configure bandwidth control (only ICMP) in a ROUTER but in "both" ways. From PCA to PCB I want to configure 200K, and from PCB to PCA I want to configure 400K. This configurations are done because I want to avoid excessive traffic that can be increase the process of my router. There is other kind of traffic passing through these interfaces must not controlled:

PCA ----> G1/1 ROUTER G2/2 ----> PCB

PCA <---- G1/1 ROUTER G2/2 <---- PCB

1.- What is better? traffic-shape or policy-map?

2.- If I use traffic-shape, in wich interface do I must apply?

3.- If I use policy-map, in wich interface do I must apply?

4.- Is the following configuration correct?

PCA=10.10.10.10, PCB=20.20.20.20

access-list 110 remark LIMIT PCA to PCB

access-list 110 permit udp host 10.10.10.10 host 20.20.20.20 eq snmp

interface G2/2

traffic-shape group 110 200000

access-list 120 remark LIMIT PCB to PCA

access-list 110 permit udp host 20.20.20.20 host 10.10.10.10 eq snmp

interface G1/1

traffic-shape group 120 300000

Normally, traffic-shape is used in the outside of the interface, but with this, there is passing a lot of traffic to the router. With "policy-map" is more efficient? Can you send me an example please?

Thanks for your help!!!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Edison Ortiz Tue, 11/25/2008 - 14:11

With MQC (Modular QoS CLI), you get more options within the shaping mechanism.

First, you create a class-map where you can match against an ACL (just like you've done above) or using NBAR among other things.

Here is the list of options under class-map:

match ?

access-group Access group

any Any packets

class-map Class map

cos IEEE 802.1Q/ISL class of service/user priority values

destination-address Destination address

discard-class Discard behavior identifier

dscp Match DSCP in IP(v4) and IPv6 packets

fr-de Match on Frame-relay DE bit

fr-dlci Match on fr-dlci

input-interface Select an input interface to match

ip IP specific values

mpls Multi Protocol Label Switching specific values

not Negate this match result

packet Layer 3 Packet length

precedence Match Precedence in IP(v4) and IPv6 packets

protocol Protocol

qos-group Qos-group

source-address Source address

Once you have a match, you can shape the target traffic under a policy map, the shape command also offers more options that the command above:

shape ?

adaptive Enable Traffic Shaping adaptation to BECN

average configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc only per interval

fecn-adapt Enable Traffic Shaping reflection of FECN as BECN

fr-voice-adapt Enable rate adjustment depending on voice presence

max-buffers Set Maximum Buffer Limit

peak configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc+Be per interval

An example would be like:

class-map PCB<->PCA

match ip access-group 120

policy-map PCB<->PCA

class PCB<->PCA

shape average 300000

interface g1/1

service-policy output PCB<->PCA

HTH,

__

Edison.

Please rate helpful posts

Joseph W. Doherty Wed, 11/26/2008 - 03:58

I think you post raises 3 issues.

Whether to use older or newer shaping syntax.

Whether to shape or police (not actually asked).

Whether either will avoid extra traffic increasing processing to the router itself.

For the first issue, like Edison, I would recommend the newer policy-map syntax. Likely where the old and new syntax overlap in function, the same IOS code might support both, but the policy-map allows many additional featurs.

For the second issue, shaping queues traffic that exceeds the bandwidth limit and I think it can only be applied in an outbound direction. Policing, however, drops overspeed traffic and can be applied inbound. Since the shaping might only regulate outbound speed, and it still needs to contend with inbound traffic, it may not offer as much reduction to router load as policing may. Policing, though, since it does drop packets, might adversely impact the SNMP applications.

Your third issue, avoiding loading the router, might be somewhat difficult to accomplish with either shaping or policing. If there's so much traffic passing through the router, that the volume is more than the router can process, neither shaping or policing within the same router may offer enough relief. I'm unsure the impact either might have, since usage of additional QoS features tend to increase router load. However, of the two approaches, policing traffic as it immediately enters the router, I would suspect, would offer the most load reduction benefit, if there is one.

Below are example of both policing and shaping using policy maps. (I'm assuming we're using a router and not a L3 switch, and the IOS is of recent vintage. Also, my syntax might be off.)

class-map match-all yourClass

match protocol SNMP (I think that's in NBAR)

(shaping)

policy-map shapePCA2PCB

class yourClass

bandwidth 200

shape average 200000

policy-map shapePCB2PCA

class yourClass

bandwidth 400

shape average 400000

interface g2/2

service-policy out shapePCA2PCB

interface g1/1

service-policy out shapePCB2PCA

*or*

(policing)

policy-map policePCA2PCB

class yourClass

police average 200000

policy-map policePCB2PCA

class yourClass

police average 400000

interface g1/1

service-policy in policePCA2PCB

interface g2/2

service-policy in policePCB2PCA

Actions

This Discussion