Greetings again.
I wanted to clarify the information I supplied regarding how Cisco
IOS uses the values you specify for traffic shaping on its ATM
interface.
You see, we (the telco) went through a similar situation with a
customer about PCR settings between our ATM switching equipment
and their ATM equipped Cisco router. By using NetTest 95000
protocol analyzers, we were able to determine that the customer had
to specify their traffic shaping config values with respect to 48 Byte ATM
cells to obtain the throughput they had requested.
What I did NOT mention was that the customer was using a 4700 with
an ATM NPM. It seems this is an older ATM interface with a SAR
ATMizer BX-50 chipset - The customer is using 12.1 IOS, and to this day,
still has to configure their traffic shaping values with respect to 48 Byte
ATM Cells... (i.e. 150 kbps really gets you 150 kbps of throughput).
It seems this is not the case for the newer ATM interfaces. I had a
closer look at the performance of a PA-A3 in a 7204 VXR, and discovered
that traffic shaping parameters for this beast are configured with respect
to 53 Byte ATM Cells (i.e. 150 kbps really gets you 135.85 kbps of
throughput). Newer ATM interfaces I've seen have a SAR ATMizer II chipset.
In your case you have an ATM interface for a 36XX series - chances
are its a newer type interface and uses the 53 byte cell calculation.
Here's something interesting: The interface counters for an ATM
interface count bytes and packets with respect to the adaption
layer you configure. Hence, in your example, the packet counters
on the ATM interface will count AAL5 frames. I observed in
12.1 on the 72XX that the output packet counters will count all
bytes in the payload of the AAL5 frame to send + 8 more. I believe
the extra 8 Bytes are the 1483 headers (SSAP/DSAP/UI/OUI & Prot Type).
The CPCS AAL5 trailer is not counted probably because it could include
padding (to make the AAL5 frame fit into a whole number of cells).
What's even more interesting are the input counters... They appear to
count everything (including the CPCS trailer) minus the FCS of the
CPCS trailer.
My apologies for leading you down the garden path...
GW
At 02:24 PM 5/11/2001 -0400, Pat Trainor wrote:
>List,
> When the telco gives us a SCR and PCR for our OC-3, we need to
>convert it to kbps to avoid policing violations at their switch. CCO says:
>
>kbps = (cps * 48 * 8) / 1024
>
> cells per second
> 48 bytes (payload) per ATM cell
> 8 bits per byte
> 1024 bits/kbit
>
> ..but there is still a quesiton here concerning the value of 1024
>or 1000 as the bits/kbit value.
>
> Additionally, is the above figure of a full 48 bytes for payload
>still valid when the circuit is a PVC? As in:
>
>interface ATM1/0.37 point-to-point
> description 1536 PVC to POP
> bandwidth 1536
> ip address 1.2.3.4 255.255.255.252
> no ip directed-broadcast
> atm pvc 1 1 37 aal5snap 1536 1536 100
>!
>
>..with a FR circuit on the other side..
>
>Cisco 3662, ATM card, OC-3, v12.0, ...
>
>TIA!
>
>pat
>:)
>
>http://ptrainor.title14.com
>"While it's true winning isn't everything, LOSING IS NOTHING!" -Ed Bighead
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:37 EDT