I have an issue, maybe someone has some insight they an share.
My company has 20+ sites that are both frame relay and ATM. These sites all connect to our data center which has an ATM DS3. The remote sites that are on ATM are being converted to frame relay, some have multiple T1's (which are now in ATM IMA groups).
We are in provisioning on the first of a dozen sites being cut over to frame relay. We cut over several days ago on a site with 4 T1's that are MFR. Since the cutover we've had several bounces on the link, due to EIGRP goodbye's being sent from the far end (data center). ATT is seeing header encapsulation errors that they say point to the DS3 side of the link. The current encapsulation on the ATM DS3 subinterface is aal5snap. ATT recommended changing to aal5mux (which we did) and it went from bad to worse. We were able to stabilize the link by changing the MTU to 1500 on each side, though ATT is saying it should be 4472. My questions after all this are:
1) Is it possible the issue is in ATT's backbone, where the ATM to FR translation is occurring? How would I find this out?
2) What should the MTU be set at on both sides of the link?
3) Considering all our single T1 FR to ATM sites use aal5snap and work fine, why would we need to change to aal5mux (and what protocol keyword do should be used after it. ATT said to use aal5mux frame-relay, there are several options, IP being most notable).
4) Is there any "acceptable" level of this type of error that should be of little or no concern?
I could use some advice on how to determine who "owns" this problem.
Appreciate any input.