atm vbr-nrt configuration for a 4 port t-1 ima card

[j-cutler]

I have a 3745 running 12.3 IOS with an atm 4 port ima card muxing 4 atm t-1's from mci with a sustained rate of 3.072 meg and a peak rate of 6.092 meg. I am trying to set the vbr-nrt for this on the subinterface,

2 questions

1. with a configuration of vbr-nrt 3072 6092 what should the mbs(maximum burst size) be in cells ?

2. I am seeing CRC and Length violations on this link despite the vbr-nrt should I lower the mbs ? It is curently set to 760 ?

[tiknapp]

Hello,

To answer your questions.

It depends. The reason why is that the MBS is going to dictate HOW LONG you will be allowed to run at the peak rate. Also note that you have vbr-nrt 3072 6092, this is not a valid configuration, you can't have a peak rate that is less than the SCR. The correct representation sould be vbr-nrt 6092 3072. Back to the question at hand... If the MBS is going to regulate the peak rate (and assuming you are doing 6092 3072) the number (in CELLS) you define for the MBS will keep the peak rate running longer (or shorter). A value that does not conform with what the carrier is policing at could cause the symptoms you are seeing in #2.

If you are bursting longer than what the carrier has defined through policing, they'll see this as non-conforming traffic and will set the CLP bit. Depending on if the carrier is doing tag & pass or tag & drop your results could vary.

Let's say they are tag & drop since it appears you are seeing some symptoms of this. Non confirming CELLS will be droped. What happens on your end is that the router will try and re-assemble the original PACKET (post sar) but the entire cell stream will not be present, so the router is going to log a CRC error. The most simplistic way to think about it is like this...

R1----(ATM)----R2--E-|

If R2 received a 1500 byte packet from the ETHERNET, it would be sending out 32 cells toward the ATM cloud. (After the SAR process)

R1----(ATM)----R2--E-|

<<<32 cells <<<1500 byte packet in from Ethernet.

Now let's say for example that 5 cells were dropped before reaching R1. R1 only receives 27 cells and tries to rebuild the 1500 byte packet. For obvious reasons, it will not be able to and will log a CRC error.

R1----(ATM)----R2--E-|

<

You are also seeing LCVs (Length violations). This will usually happen if the last in series cell is some of the traffic being dropped in transit. The router will not be able to differentiate between the cell streams and can try and combine multiple cell streams into a big packet. Since the result will be oversized, it's going to record a LCV.

So you'll want to check with the carrier to find out if the burst you've configured is causing non-conforming traffic (meaning they will set the CLP bit on your traffic if you burst too long).

...2 simple questions, one big answer. :)

Hope this helps.

-Tim

[j-cutler]

Thanks Tim,

I do have a poliy of 6092 3072 760 ( I reversed them in the question ) on the router.

Any way of calculating the mbs rate from the pcr and scr ?

[tiknapp]

Sure, you can break it down and find out how many cells per second are going to be introduced the steps are here.

http://www.cisco.com/en/US/tech/tk39/tk51/technologies_tech_note09186a0080102a42.shtml#cellspersec

BUT this isn't going to tell you WHAT to set the MBS to. The burst time will depend on how the carrier is policing. They will need to tell you how long you are permitted to run at 6092kbps for you to set the MBS. Remember if you burst too long then the carrier is going to see this as non-conforming traffic and will set the CLP and most likely discard your traffic.

A simple test to determine if the burst is causing the CRC's is to lower the PCR = SCR this way you'll just have a 3072kbps pvc. If there are no CRC's with this setting then you know for sure that the burst is causing the non-conforming traffic.

Then all you have to do is work with your carrier to find out how long they will let you run at the peak rate and set your mbs accordingly.

Hope this helps...

-Tim