e1 slip errors

[scoe]

strange problem......

2650xm router with a NM-HDV module and a VWIC MFT E1 module connected to PSTN ISDN-30 PRI. It's worked ok for years but now gets slip secs and error secs clocking up.

We have replaced the NM-HDV and the VWIC twice and now the router and they are still appearing so from this you would say it's definately not a router hardware issue.

If you plug a different 931 ISDN-30 into the router the errors still appear on the routers e1 controller and if you plug the original circuit into a different but identical router there are no errors, so from this you would say it's not a circuit problem.

Any ideas? Could it be an earthing problem?

[pkhatri]

Hi,

Slips are usually caused by clocking mis-configuration. How have you configured the clocking on this circuit ?

Maybe the controller config and the output of 'sh controller e1' may help ...

Regards,

Paresh

[scoe]

Hi Paresh,

the router has been in and working for a number of years before errors started appearing, so not a config issue. The clock comes from the PSTN.

show cotroller e1 output..............

E1 1/1 is up.

Applique type is Channelized E1 - balanced

Description: *** NTL PSTN PRI cct G09-02-42 primary incoming, secondary outgoing

No alarms detected.

alarm-trigger is not set

Version info Firmware: 20020812, FPGA: 11

Framing is CRC4, Line Code is HDB3, Clock Source is Line.

Data in current interval (92 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

5 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

5 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Total Data (last 24 hours)

0 Line Code Violations, 0 Path Code Violations,

3957 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

3957 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

[mparramo]

Hi :

These platforms (2600s) don't have a TDM bus (even though there are commands to define the clocking to the TDM bus), so I think that it would be a good idea to check if you have the following commands:

network-clock-participate slot/wic x

network-clock-select x E1 x/x

If you do please remove them, do a clear counters and monitor for at least 10 min if the Slip counters increase, removing these commands won't cause any problems with the E1 (like going down or something), Slips errors normally cause problems with Faxes, modems and Static sound.

[scoe]

Thanks for your reply. The network-clock commands are not configured.

We have more information though. There is a PBX connected to the same router via a 2nd E1 PRI and if we disconnect the PBX the errors cease on the PSTM E1 !

Furthermore, if we connect the PBX to another identical router which also has a PSTN connection errors start appearing on this E1 too.

So the when the PBX is connceted on one E1 it causes errors on the other E1 in the same router connected to the PSTN. Must be a clocking problem, but other than disconncting the PBX I can't think of how to fix it.

Any ideas?

[pacameron]

The slips are caused by a slight difference in the clocking between the PSTN and the PBX interfaces.

The VWIC card has a single phase locked loop (PLL) device that is used to recover the clocking from either of the interfaces , it then uses this recovered clock signal to drive the transmit direction - this ensure the recieve and transmit are referenced to the same clock source.

If there is a difference in the clocking coming in on port 0 and 1 , the PLL cannot properly sync up to both signals, so it will the clocking on one port as the reference, this then causes the second port to register slips due to the timing differences.

The fix is to set the second port as 'clock source internal'. This tells the E1 card PLL to recover the clock off port 0 and use it to send data out port 1. If the PBX is set up to accept clocking from it's E1 interface, we maintain a common clock reference. If the PBX has an external PBX connection, it would be using this is it's master reference, but since the clocking coming in the router E1 port is synced to this external source we have maintained a common reference from the router.

Give this a try and see if it helps.