I have problem with two remote locations (ATM on central site, FR on remote locations, virtual templates because of iptel). They are sufferin from poor iptel quality in receiving direction. All I can see is lost fragments in ppp multilink command result. Configuration of templates is the same as for other 20 locations that do not have these problems, central site router is 7204vxr 12.3(16). How can I further debug this and find problem?
can you involve the provider to clarify any discards in his network? It could simply be an overload situation in the SP network leading to some discards.
What is your PPP fragment size? Could be preferable to adjust it to an ATM AAL5-frame size fitting into cells (Nx48 byte) nicely.
great! thanks for supporting my theory. :-)) I've involved SP and they told me that they see CRC errors from central site to remote site, wich results in discards in their network. I think it is strange, they should not discard anything I send. I guess that lost fragments are result of this. But SP told me it is problem on our side. I am using ppp multilink fragment delay 10 on virtual template so for this two links I have problem with frag size is 270. I also have several other locations with this frag size and those locations do not have problems.
it could also be faulty hardware or cabling (electro-magnetic interference). So you could try to swap cables first and router next.
However, if the errors occur from central to remote, where exactly do they occur? CRC means bit errors and the question is on which line are they happening? If they claim central site to first SP equipment, why are no other sites involved?
Can you/they be more specific about "CRC" (Layer1, Layer2, AAL5, FR?) and where they detect them?
well, this is all I get from provider. All PVCs goes through same cabling to provider so do not think it is cabling. CRCs are on layer3 level, but from central site to remote, provider do ATM to FR transform. Attached is picture I got from provider. They did testing with their ow FR test device, and loop somewhere in their cloud
this shows, that your FR equipment does not create the CRC errors, because RX is "clean". TX is the problem with CRC errors at about 2.5%, which is unacceptable for VoIP.
So you need to get your ATM statistics (The hardware is a Cisco MGX and technically they can provide you with those statistics!).
From those you can deduct, whether the CRC errors are happening in the SP network or are received from your router.
Hope this helps! Please rate all posts.
Hi, this is the ATM part of the connection terminating on a BPX. All cells received are sent to the network. This means no HEC errors, which would indicate Bit errors in the cell header. But the collection time for the statistics was only 10 minutes, so not too much of an indication.
With 2.5% Frame CRC rate and assuming statistically distributed Bit errors about 48/1500 (one cell out of a frame) *5/53 (header portion of ATM cell) *2.5% * 20000 errors in the cell headers equal to about 1 cell. So a collection time of at least one hour should be used to see any problems there.
As your other locations do not have any problem I would assume the problems to be in the FRSM part, which does ATM-FR interworking or in the transportation because of overload drops in the ATM switch trunks.
Summary: no (obvious) problems from Central site to ATM switch, obvious problems from SP network to FR site.
Conclusion: SP problem!
Hope this helps! Please rate all posts.
well ... how come that measurement that provider did was ok. They connected to remote location FR line, put correct DLCI in device, closed loop in ATM network and everything was fine. Is it possible that here is kind of problem with encapsulation? I am using virtual-templates, and ppp, and rtp and tcp header compression. But my other locations use this and do not have problems. ... Somethimes I hate networking :-)))
Well the only thing could be FR encapsulation on the router must be "encapsulation frame-relay IETF", ATM must be aal5snap, otherwise you can get discards with ATM-FR conversion. All other stuff contained in the FR frames is just transparent to the FRSM.