[c-nsp] cisco 2901 qos

[Michael Sprouffske]

I just increased polling on that interface to see if maybe we are getting bursty traffic that is filling the queues.  It might be that we are filling the interface and not knowing it because polling was set to 30 seconds.(LOL)





On Tuesday, November 5, 2013 12:24 PM, Michael Sprouffske <msprouffske at yahoo.com> wrote:
 
I don't see that my link every really goes over 7mbps.  Thats what has me baffled.  If there is still room on the link then why are we getting output drops on that one queue?





On Tuesday, November 5, 2013 12:18 PM, Tony <td_miles at yahoo.com> wrote:

If you are getting that many drops and it is unacceptable then you need to seriously think about increasing the amount of bandwidth you have available.

Changing queue-depth may help, it will mean packets will sit in the queue for longer before being potentially dropped. This would only help if the congestion is temporary. What does a traffic graph of link utilisation say ?  

You've allocated 80% of the bandwidth to more important classes, leaving only 20% left for default class (ie. 2Mbps on 10Mbps shaping). If the other classes are always using their max bandwidth and you have more than 2M of other traffic then you will have drops. Bigger queue's will only help if your bandwidth usage is bursty not if you are saturating the link (ie. there is no space on the link due to
burst, so queue it until burst goes away then transmit). Normally the default queue depths are sufficient on a link of this size.

QoS will allow you to decide which traffic is more important and so guarantee it some bandwidth on the link. During periods of congestion any traffic isn't guaranteed an amount of bandwidth is subject to being dropped. QoS isn't magic and can't make a 10M link do any more than 10M.



regards,
Tony.



________________________________
From: Michael Sprouffske <msprouffske at yahoo.com>
To: Alex Pressé <alex.presse at gmail.com> 
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net> 
Sent: Wednesday, 6 November 2013 5:29 AM
Subject: Re: [c-nsp] cisco 2901 qos


I get 1
millions drops per day from the best-effort.  Is there anything that can fix this?  Do I need to adjust queue depth and if so , what would you recommend.






On Tuesday, November 5, 2013 11:20 AM, Alex Pressé <alex.presse at gmail.com> wrote:

You are doing it right; all traffic will be shaped to a max of 10M; with best effort getting at least 2M (or more, if there is no congestion).

class-default just matches everything that hasn't been matched already. In this case you're matching everything and then applying child policies. Within ELA_QUEUING_POLICY you might also have class-default statements - simply to match non IP traffic (depends on purpose of
link).



On Tue, Nov 5, 2013 at 12:00 PM, Michael Sprouffske <msprouffske at yahoo.com> wrote:

class-map match-any Best-effort
> match ip precedence 0  1
>class-map match-any Priority-Three
> match ip precedence 2  3
>class-map match-any Priority-Two
> match ip precedence 4  6  7
>class-map match-any Priority-One
> match ip precedence 5
>!
>!
>policy-map ELA_QUEUING_POLICY
> class Priority-One
>    bandwidth percent 40
>    
random-detect
> class Priority-Two
>    bandwidth percent 20
>     random-detect
> class Best-effort
>    bandwidth percent 20
>     random-detect
> class Priority-Three
>policy-map ELA_SHAPING_POLICY
> class class-default
>    shape average 10000000
>  service-policy ELA_QUEUING_POLICY
>
>Does this actually shape my trafffic for the class-default if i'm matching best-effort on ip pres 1 and 0?  Or does that shape command need to be in the class best-effort and say remove the class-default?
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/