710
Views
0
Helpful
1
Replies
Limit input Traffic so specific class not interrupted
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2018 03:51 AM - edited 03-08-2019 03:56 PM
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..
Labels:
- Labels:
-
LAN Switching
1 Reply 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2018 05:54 AM
"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.
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.
