[28226] in North American Network Operators' Group
Re: Anyone encountered Cisco ATM PVC large delay bug?
daemon@ATHENA.MIT.EDU (Ron Buchalski)
Thu Apr 20 21:15:13 2000
Message-ID: <20000421011307.22623.qmail@hotmail.com>
From: "Ron Buchalski" <rbuchals@hotmail.com>
To: yuning@cndata.com, nanog@merit.edu
Date: Thu, 20 Apr 2000 18:13:07 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Errors-To: owner-nanog-outgoing@merit.edu
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
