What type of service are you using? UBR? VBR? Some things to know... 1) Setting parameters such as PCR, SCR, MBS on the ATM interface will insure that you are shaping your traffic properly for the ATM cloud. What it _doesn't_ do is shape your IP traffic to go into this shaped ATM PVC. If your IP traffic exceeds your SCR occasionally, the SAR txpools can handle the bursts. However, if you exceed your SCR by a significant amount, the SAR txpools will fill, and you will encounter high queuing delays (as you've seen). 2) By default, one SAR txpool is created, and all PVCs share the pool. If you have one PVC which exceeds it's SCR, it will "hog" the SAR txpool and starve the other PVCs which are operating within SCR limits. So, one offending PVC will affect all other PVCs sharing the SAR pool. To fix this, you can create additional SAR pools and assign PVCs to different pools. You can create a maximum of four SAR pools. 3) The best way to manage this situation is to use the Class of Service per-VC queuing feature. This will create a separate queue for each PVC, and will insure that offending PVCs don't affect other PVCs on the same interface. What it will also do is link Layer 2 traffic engineering (ATM traffic shaping) to Layer 3 flow control by using WRED to throttle TCP flows on PVCs which are exceeding their ATM PVC limits. As the TCP windows close, the packet flows will be reduced until they fit within the shaped PVC's limits. When you enable the CoS per-vc queuing feature, you no longer need to configure SAR txpools, since it will be under software control. This feature is available in 12.0S code for both GSRs and 7x00 routers. Distributed CEF mus be enabled on the 7500 to use this feature. Hope this helps. -rb

From: "Yu Ning" <yuning@cndata.com> To: "nanog-post" <nanog@merit.edu> Subject: Anyone encountered Cisco ATM PVC large delay bug? Date: Fri, 21 Apr 2000 07:28:21 +0800

Hi nanog,

I'm not sure how many percentage of global NSP/ISP use ATM PVC to provide links between their Cisco routers. It seems there is some large delay bugs in Cisco ATM interface, esp on GSR level routers.

In more detail, our situation is: if we get a high bandwidth PVC, say 51M(or 80M), and if the bandwidth utilization reaches 80% percent, the ATM link will encounter a 1500~2000 ms delay - just point to point ping across the link. We have found this situation is associated with "sar txpool" setting in Cisco GSR, and a manipulation of the "sar txpool" together with bandwidth increasing has solved the problem now.

But I still wonder if any of you ever encounter this situation(bug), and how did you overcome it? If you are still puzzled by this bug, I'd like share our temp solution with you.

________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com