Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Sanity-Check of QoS over ATM


I believe this is right but my understanding of the intricacies of ATM is fuzzy enough that I would like confirmation.

Here is the scenario: 2 sites connected via a sometimes-congested 4mb ATM (4 T1's) link and all traffic is given a DSCP at ingress to the network as follows:

Voice and VTC signaling traffic: cs3

Voice Media Traffic: ef

VC Media : AF41

Everything else: 0

I need to:

Provide a LLQ for the Voice media and guarantee at least 256Kb BW

Guarantee at least 45k for VC and voice signaling

Guarantee at least 450k for VTC

Fairly handle whatever BW is left for everything else

Here is my config:

class-map match-all VC

match dscp af41

class-map match-all voice-rtp

match dscp ef

class-map match-all voice-signal

match dscp cs3



policy-map EC

class voice-signal

bandwidth 45

class voice-rtp

priority 256

class VC

bandwidth 450

class class-default

interface ATM3/ima2

description "IMA links to EC"

ip address

ip pim sparse-dense-mode

ip nat inside

ip virtual-reassembly

ip route-cache flow

load-interval 30

no atm ilmi-keepalive

crypto map RK-EC-IMA

pvc 0/16

protocol ip broadcast

protocol ip broadcast

service-policy output EC

First, does anyone see any issues with this working and second, what commands can I use to verify that it is doing what I think it should?


Nathan Spitzer

Super Bronze

Re: Sanity-Check of QoS over ATM

One issue I've found, on many of the non-7500 platforms, class-default FQ appears to distort the minimum bandwidth allocations for other non-LLQ classes. To avoid this, I either just use LLQ and class-default with FQ, or switch class-default to FIFO. If you chose to just use LLQ and class-default FQ, you could move your other classes to LLQ and/or allow them in class-default which normally uses WFQ (NB: where they should obtain more bandwidth because of their higher ToS markings vs. BE marked flows).

On ATM links, at least with some IOS revs., when supporting real-time traffic, you might also need to decrease the tx-ring-limit. For 4 Mbps, the minimum setting might be acceptable.

"Show policy-map interface output" should indicate how the policy is working.


Further on the subject of "working", I wonder about, configured on the ATM interface, "ip pim sparse-dense-mode", "ip nat inside", and "crypto map RK-EC-IMA". Depending on the type of ATM PVC, you might also consider defining a point-to-point subinterface. Also, if your PVC is something like a vbr with a SCR much smaller than the PCR, you might need to examine how that might impact your real-time traffic.

CreatePlease login to create content