ATM to Multilink Frame Relay - Header Encapsulation errors

[chharris41]

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.

Thanks!

[paolo bevilacqua]

Hi,

is not an easy problem the one you are having.

Few points:

1) Not really. Most likey they are doing that with a BPX-type WAN switch. Since a BPX network is all ATM internally, it is difficult to defined exactly where the conversion occours.

2) MTU should be like 1600. That is the recommended value for the FR side. In fact even 1500 is fine. No advantages in having it bigger.

3) If the device doing the ATM/FR interworking is working correctly, it should work with all the encapsulation types. If aal5snap works bettes, keep it. It has only a small overhead compared to aal5mux.

4) really none is acceptable. You should see if these matches physical errors, in which case one would understand the reason why, and be able to fix it.

Hope this helps, please rate post if it does!