[c-nsp] QOS Config Example

Mike Butash der.mikus at gmail.com
Sun Aug 27 08:01:07 EDT 2006


Check out:

http://www.cisco.com/en/US/netsol/ns656/networking_solutions_program_category_home.html

and particularly:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf

The SRND's define a standard framework which works pretty well actually, 
at least until you end up interoperating with *external* networks that 
don't exactly conform to these models.  MQC is generally flexible enough 
to allow for this with tweaking, however, but can require some 
forethought.  If you are to use certain ip-provisioned services for 
transport that adhere to different levels of interface and class queuing 
aside from these, mutations might need to occur.  SRND's give you a 
decent initial framework for just about every standard cisco platform to 
tweak as desired from there.  If a device freaks out for some reason, 
call tac and reference them to their own documentation.  :)

-mb



Robert E. Seastrom wrote:
> "Paul Stewart" <pstewart at nexicomgroup.net> writes:
> 
>> Thanks... I should have focused more on that area yes.... For sure....
>>
>> That area concerns me the most but yet I feel I have very little control
>> over it and not a lot I can do... The DSL network is 3rd party in most
>> circumstances and we have no control over what CPE equipment that they
>> use....
> 
> Well, if you give them something like the Linksys VOIP box that is
> also a NAT firewall, then some percentage of people will put that box
> first in their network config (ie, facing you).
> 
> Have you had any kind of problems or are you just anticipating them?
> Torrent is pretty worst-case - opening up a few dozen TCP streams and
> letting them duke it out on backoff with tail-drop nastiness and all
> is not a really pleasant situation, either for the BT stuff or for
> anything else that might happen to be trying to share the same pipe.
> The usual rules about TCP just stepping out of the way for an RTP
> stream don't necessarily work when someone is hammering the snot out
> of their upstream b/w.  You might however find that quality is OK or
> that you can find a sweet spot - most torrent clients I've seen let
> you cap the output, either by kbit/sec, number of streams, or both.
> If you embrace the fact that people are in fact buying your service in
> order to use it this way, and put a "recommended BT settings" section
> on your customer support web site, things might just turn out OK with
> nothing done in terms of cute tricks with the routers.
> 
>                                         ---Rob
> 
> 
> _______________________________________________
> 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/
> 


More information about the cisco-nsp mailing list