[c-nsp] QoS ATM sub interface

[Jason Berenson]

Nathan,

- We prioritize signaling because if one starts to lose OPTIONS messages 
for example the call will be torn down.

- How can I run that without an ACL?

- Nothing useful in the logs and nothing gets printed to console.  We 
need to have different QoS maps for custom jobs so applying a map just 
to the main ATM interface isn't doable.  It has to be applied to the VC 
since we're using CBWFQ:

router(config-subif)#  service-policy output voice
CBWFQ : Not supported on subinterfaces

I checked Ciscos site and this policy should be fine on the VC.  Here's 
the old policy I was using:

policy-map voice
 class voice-signaling
  bandwidth percent 5
 class voice-traffic
  priority percent 70
 class class-default
  fair-queue
  random-detect

We were matching on mostly IP/ports with the old one.  Also, we aren't 
going over the 75% limit of reserved bandwidth on the interface so 
setting max-reserved-bandwidth 99 did not help.

Thanks,
Jason

Nathan wrote:
> On Thu, May 22, 2008 at 12:12 AM, Jason Berenson <jason at pins.net> wrote:
>   
>> Greetings,
>>
>> I've recently simplified QoS on our edge routers.  Here's what we're using:
>>
>> class-map match-any Core_Voice_Signaling
>> match access-group name Core_Voice_Signaling
>> class-map match-any Core_Voice_RTP
>> match access-group name Core_Voice_RTP
>>
>> policy-map voice
>> class Core_Voice_Signaling
>>  bandwidth percent 5
>> class Core_Voice_RTP
>>  priority percent 70
>> class class-default
>>  fair-queue
>>  random-detect dscp-based
>>
>> ip access-list extended Core_Voice_RTP
>> remark DSCP 24 = TOS 3
>> permit udp any any dscp cs3
>> remark DSCP ef
>> permit udp any any dscp ef
>>     
>
> You could run that without any access-list. I expect/hope that would
> be less resource-intensive.
>
>   
>> ip access-list extended Core_Voice_Signaling
>> remark SIP Signalling
>> permit udp any any eq 5060
>> permit tcp any any eq 5061
>>     
>
> That does need an access-list though. Pity. Personally I don't do it,
> either signalling is in the AF class, or it piggybacks on the EF
> class, or it doesn't get prioritized. Is there anyone who can give an
> example of voice problems experienced when signaling packets get
> delayed or even lost?
>
>   
>> For some reason when I apply 'voice' to an ATM sub-interface it doesn't
>> seem to show up under the show policy-map interface command.
>>     
>
> Isn't there something in the logs? I don't know what log-level it is,
> I usually run debugging, and when a service-policy is not applied
> there is is never any error in the session like there would be if
> there was a syntax error, but always something useful in the logs.
> Turn on "terminal monitor" . . .
>
>