[nsp] dscp setup

[Roger]

Oliver Boehmer (oboehmer) wrote:

> Your approach seems to achieve what you have in mind. I'd still worry
> about your class-default, i.e. all traffic not matched by either one of
> your ACLs. Based on your policy you don't give any treatment to this
> traffic. By default you'll only allocate 75% of the interface bandwidth
> to your two classes, so class-default will share the remaining 25% with
> all other traffic like routing updates/keepalives/etc. Please make sure
> if this is what you want/need. The 75% value can be changed using the
> max-reserved bandwidth interface comment.
>
>  
>
Thanks for your assesment..  Glad I was at least on the right track..

Would I see any addition benefit from marking those packets w/ the dscp 
value of 'ef'

I know this traffic classification is normally reserved for VOIP, I'm 
just looking to setup this traffic w/ the lowest latency possible...


> Please also bear in mind that allocating such a large priority queue can
> really slow down your other traffic.
>
>  
>
Yes - I'm robbing Peter to pay Paul... :|

> You're mixing terms/concepts here. DSCP by itself is way of marking, GTS
> is queuing. With your config approach you are using DSCP for marking and
> CBWFQ/PQ for queuing, and this is what I'd do.
>  
>
Ok, I've used GTS before to slow/limit traffic flows, but I'lm treading 
into unknown places here.

Also does DSCP/GTS/PQ behave differently across frame-relay t1s?

> Well, this depends on the other routers' configuration/policy. If they
> reset the dscp to zero, there is not too much point for you setting the
> dscp value in the first place, and you can simplify your config by
> getting rid of the inbound policy map (setdscp) and its classes and
> configure
>
> policy-map manage
> class sensetive
> priority percent 70
> class insensetive
> bandwidth remaining percent 30
>
> on your outgoing interface.
>  
>
Ok - yes.  I'll have to talk to my upstream provider and see what their 
policy is on that.

> I hope I was able to clear the fog a bit I agree QoS/DiffServ can
> get quite complex..
>  
>
Good deal - thanks!