cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Bookmark
|
Subscribe
|
710
Views
0
Helpful
1
Replies

Limit input Traffic so specific class not interrupted

achridhan
Level 1
Level 1

Hello Experts..
I have some case that some of my router (Cisco IOS C870) return ping rto while traffic is full.
And so far I try this idea..
"limit the input so there is some space for telnet and icmp protocol" or "increase priority of telnet and icmp other than that is low priority"
I try using code below.. 

class-map match-any Critical
 match protocol telnet
 match protocol icmp

policy-map QOS_512_IN
  class Critical
  set precedence 7
  class class-default
  set precedence 3
   police cir 256000 pir 460000 conform-action transmit exceed-action set-prec-transmit 1 violate-action drop

result are traffic still high.. 

  30 second input rate 505000 bits/sec, 53 packets/sec
  30 second output rate 25000 bits/sec, 45 packets/sec

and ping still rto

Success rate is 66 percent (66/100), round-trip min/avg/max = 16/22/56 ms

I'm looking forward if there any way to make this happen.. 

1 Reply 1

Joseph W. Doherty
Hall of Fame
Hall of Fame
"I'm looking forward if there any way to make this happen.. "

Using your approach - maybe. Your policed traffic needs to be speed adaptive traffic (e.g. TCP) and you often need to police such that you allow for lots (e.g. 75% or more, i.e. you might try policing traffic above 25% or less) of bandwidth for your "critical" traffic. (This because you're trying to get your senders to not use all your bandwidth before they detect drops and slow their transmission rate.)

Because you often need to police to such a low percentage, you effectively lose much of your available bandwidth. Even then, again, this assumes all your flows will slow when they detect policed drops.

Also BTW, for your purpose, don't use peak policing and you may need to decrease your burst measurement interval. Also I would recommend you don't tag your "critical" traffic with IPPrec 7, I would recommend no more than IPPrec 4, or possibly IPPrec 5.

The optimal way to deal with your situation is to manage traffic on the "other side", but from what you've described, don't know if that's possible.