Currently PRI is coming in from provider on T1 fed 924e and is fine.
Tried to move to an ethernet fed 924e and seeing tons of timing errors and CRC errors on the PRI interface.
Cable is the same from 924e to PBX and the problem clears when put back into the T1 fed 924e.
Caz70,
Thanks for posting! Generally speaking, when you have a unit with a T-1 interface facing an ISP or carrier, that should be the primary clock source. Units that have an ethernet interface facing the ISP will be set to internal clocking. Below are a few examples.
! Single T-1 facing the carrier
timing-source t1 0/1
timing-source internal secondary
! Two T-1 interfaces facing the carrier
timing-source t1 0/1
timing-source t1 0/2 secondary
! Ethernet WAN connection
timing-source internal
We may need to check the timing on the original T-1 fed 924e in order to be certain it is configured in a standard way as shown above. The output of "show system" will show you the configured and current clock source. You can also use the output of "show run interface t1 0/x" to check the overall settings for the T-1 interface facing the PBX. We will want to make sure that settings such as coding and framing match up on the new unit. If the current unit is set to receive clock from the carrier, we should be able to set the new Adtran unit to internal timing-source and run without clock slips. If the current unit is actually receiving clock from the PBX, we would need to set the new Adtran unit accordingly.
If you continue to take clock slips, there are a couple more common ways to resolve issues. First, the PBX/phone system may need to be rebooted, or its T-1 card re-seated. We often see a PBX that locks into a particular frequency. In other words, even though the PBX may be configured to receive clock, it is no longer behaving that way.
Another less common fix is to adjust the LBO setting on the Adtran unit. This is typically a trial and error process, but below is a setting with which I have had success in the past.
interface t1 0/3
lbo long -7.5
If you are unable to resolve the issue with the above information, you may need to create a Technical Support ticket by calling 888-423-8726. However, feel free to respond on this thread with any additional information or questions you may have.
Thanks!
David
Caz70,
Thanks for posting! Generally speaking, when you have a unit with a T-1 interface facing an ISP or carrier, that should be the primary clock source. Units that have an ethernet interface facing the ISP will be set to internal clocking. Below are a few examples.
! Single T-1 facing the carrier
timing-source t1 0/1
timing-source internal secondary
! Two T-1 interfaces facing the carrier
timing-source t1 0/1
timing-source t1 0/2 secondary
! Ethernet WAN connection
timing-source internal
We may need to check the timing on the original T-1 fed 924e in order to be certain it is configured in a standard way as shown above. The output of "show system" will show you the configured and current clock source. You can also use the output of "show run interface t1 0/x" to check the overall settings for the T-1 interface facing the PBX. We will want to make sure that settings such as coding and framing match up on the new unit. If the current unit is set to receive clock from the carrier, we should be able to set the new Adtran unit to internal timing-source and run without clock slips. If the current unit is actually receiving clock from the PBX, we would need to set the new Adtran unit accordingly.
If you continue to take clock slips, there are a couple more common ways to resolve issues. First, the PBX/phone system may need to be rebooted, or its T-1 card re-seated. We often see a PBX that locks into a particular frequency. In other words, even though the PBX may be configured to receive clock, it is no longer behaving that way.
Another less common fix is to adjust the LBO setting on the Adtran unit. This is typically a trial and error process, but below is a setting with which I have had success in the past.
interface t1 0/3
lbo long -7.5
If you are unable to resolve the issue with the above information, you may need to create a Technical Support ticket by calling 888-423-8726. However, feel free to respond on this thread with any additional information or questions you may have.
Thanks!
David
It sounds like a clocking issue. The rule is that every T-1 link have exactly one clock source.
Scenario 1:
T-1 from provider to TA900, second T1 PRI from TA900 to PBX:
On TA900 set primary clock source to the provider's T1 interface, secondary to internal.
On PBX set primary clock source to T1 from TA900.
Clock is originated at provider's BITS clock which drives the TA900. TA900 regenerates this to PBX. Should provider T1 go down, TA900 switches to internal and feeds PBX.
Scenario 2:
Ethernet feed to TA900 (No T1s either PRI or data from providers), T1 PRI from TA900 to PBX.
On TA900 set primary clock source to internal.
On PBX set primary clock source to T1 from TA900.
Scenario 3 (this gets tricky):
Ethernet feed to TA900, PBX has two PRIs, one from another provider, one from TA900.
Most PBXs only allow one clock source to be authoritative. Because the provider's PRI is connected, we need to clock the TA900 from the PBX.
On PBX set primary clock source to provider's T1 with secondary of internal.
On TA900 set primary clock source to T1 connected to customer's PBX, secondary to internal.
If you have a data T1 connected to the TA900 as well, its feed router needs to clock from the TA900.
Also check framing and line code. Almost all PRI and data T1s should be ESF/B8ZS on both sides. Only CAS/RBS voice T1s are D4/AMI these days. In any case both sides must be the same on each T1 link.
Caz70,
I wanted to check back in with you to see if you had found a solution. If you have further questions, feel free to reply on this thread.
Thanks!
David
Caz70,
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
Thanks!
David
Thanks David,
Will update once this gets rescheduled.