Not sure if you got this figured out but I had a similiar situation and
our SE pointed me to the policy aggregation feature in the ASR.
http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_policies_agg.html
HTH,
-Rob
hafiz atif wrote:
> Thanks Guys!
>
> On Mon, May 18, 2009 at 1:16 AM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
>
>
>> Hey yall,
>>
>> QoS is an area I need to work on ... thanks for this discussion. Dale
>> rocks! So would be good to get Dale to weigh in here too.
>>
>> Yeah, I think offering 6 classes for your customers is fairly common. You
>> keep one for real time traffic and one for Net management. Real time should
>> be w/ the priority command and net man can be with the bw remaining percent
>> command ... should not need much for this class; maybe like 5% ?
>>
>> Within the other classes you can also configure wred, dscp-based, also
>> define bw percent remaining for each of these classes. Having wred in each
>> class will offer you some granularity within each class. You can get pretty
>> deep in your customer markings and assigning the wred dscp values for each
>> each class.
>>
>> Does this mean you 'kind of' have more than 6 classes to offer for your
>> customers? Not really ... but it does offer you quite a bit of granularity
>> and allows for you to offer some customers better service within each queue
>> / class.
>>
>> On a side note, you need to make sure the ASR uses pak_priority for local
>> control traffic. It should. Just want to make sure this is not being put
>> into the class-default as once you define an outgoing policy, you might be
>> hurting yourself too.
>>
>> Unless the customer states otherwise, I would suggest to define or allow
>> FTP to fall into the scavenger class, police it, and wred it. FTP will
>> always use as much bandwidth as it can ... no doubt about it, FTP will fill
>> the link any chance it can.
>>
>> Lastly, you will need to change the max reserved bw to allow you to
>> configure 100%. The bw reamining percents should equal 100% when all is
>> said and done.
>>
>> Just some thougths, hope these make sense. Appreciate the back and forth.
>> Take it easy team,
>>
>> Andrew
>>
>>
>> On Sun, May 17, 2009 at 8:49 AM, hafiz atif <oops.com_at_gmail.com> wrote:
>>
>>
>>> the 2nd options is workable to have predefined policies for different
>>> markings and mark customers accordingly. But this will again give me only 8
>>> different bandwidth assignments which can cover more customers
>>> comparatively. Any more suggestions to make it more scalable?
>>>
>>> There is another point on which i need some suggestions. How can we
>>> control the incoming traffic? Lets say, one of the customers is requesting a
>>> download from a public FTP server. The ftp server is now sending at a rate
>>> greater than my internet bandwidth, now even if i police this download
>>> traffic on my router, my external link has already been used. Is there any
>>> work around for this? please advice!
>>>
>>> Best regards!
>>>
>>>
>>> On 5/17/09, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
>>>
>>>> Thinking out loud here and way too tired ... sorry if this is too far
>>>> off.
>>>>
>>>> Any chance that configuring nested service policies will provide more
>>>> scale? I do not know the limit to the number of nested policies within a
>>>> parent policy ... Basically you could create one policy-map per customer.
>>>> Add this to a parent policy-map with shaping configured.
>>>>
>>>> Another thought might be to configure qos on a per customer basis and
>>>> shape, protect, and remark all packets as needed on a per customer basis.
>>>> On the uplink, simply configure a single policy which provides different qos
>>>> levels for all traffic going.
>>>>
>>>> You could provide 6 or 7 classes for customers, and keep at least one
>>>> class for net management. Just a thought ...
>>>>
>>>> Not sure this helps much ... time for my bed time ... in NJ, it is a bit
>>>> too late for me. Have a good night,
>>>>
>>>> Andrew Lee Lissitz
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, May 17, 2009 at 1:52 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:
>>>>
>>>>
>>>>> Hi again,
>>>>>
>>>>> On Sun, May 17, 2009 at 3:40 PM, hafiz atif <oops.com_at_gmail.com> wrote:
>>>>>
>>>>>> I can't change the speed to 10 mbps because we are planning to
>>>>>>
>>>>> increase the
>>>>>
>>>>>> speed upto 16mbps.
>>>>>>
>>>>> In that case, even 100Mbps is better than 1Gbps. Can you interface do
>>>>> 100M, or 1000M only? I appreciate that some 1000BASE-x interfaces are
>>>>> 1000-only.
>>>>>
>>>>> cheers,
>>>>> Dale
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Andrew Lee Lissitz
>>>> all.from.nj_at_gmail.com
>>>>
>>>>
>>>
>> --
>> Andrew Lee Lissitz
>> all.from.nj_at_gmail.com
>>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Tue Jun 09 2009 - 21:06:43 ART
This archive was generated by hypermail 2.2.0 : Wed Jul 01 2009 - 20:02:37 ART