Frasi PVC to ATM - Frame errors

[umhguy]

Help guru's! This ones a toughie.

I have a T1 Frame circuit at one end and a DS3 at the other. One the frame side there's no loss of LMI or anything similar, circuit tests clean straight to to CSU. Single 768cir PVC on T1. On ATM side, there's a single pvc that's matched with PCR/SCR values of 1811/1811. The cisco is configured as similar:

interface ATM2/0.111 point-to-point
ip address 123.123.123.123 255.255.255.252
no ip mroute-cache
pvc 1/123
vbr-nrt 787 787 100

Traffic flows, but i'm seeing this on the frame side under the interface:

4850 packets input, 2677425 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
10 input errors, 10 CRC, 4 frame, 3 overrun, 0 ignored, 3 abort
6052 packets output, 2116090 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

Note the errors. We cannot find the problem. And here's the kicker. Downstream from the ATM to the frame suck, we get errors, dropped packets, etc. Upstream is perfect. Will max out the pvc, no drops, no nothing.

Help?!

 

[plshlpme]

with the frame errors ide look towards the cct being at fault.
when you have the carrier test it.. make sure they test if for more then 5 minutes...

 

[jim7498]

If you run a ping test (1500 byte packet size) are you dropping any packets? What kind of errors are you seeing on your t1 controller?

 

[artesian2000]

Who's the carrier in this. This sounds like a need to get a higher level of support is needed.

 

[killersheep]

The first thing I would do is change your traffic shaping to read slightly less than the settings on the telco switch. Probably 750 750 100 and see if you are still getting dropped packets.


You can get all kinds of weird errors when throwing too many cells at the carrier. Been doing frame/atm for a carrier myself for years and dropping your setting below the carriers has solved all kinds of weird issues with cells dropping.