Clocking DTA0017 Loop

[rjtripp]

I have been tasked with fixing a clocking problem on a CS1000 (opt.11) cabinet. I installed a clock controller daughter board on loop 3 the primary clock, 7 is the secondary. All went well with the install. Clocking is enabled and locked to loop 3. I am not getting any SLIPD on that loop. I started to monitor the system remote and am now getting SLIPD on loop 7. I then got the DTA017 7
>!
>ERR DTA017
>
DTA0017 loop
Frame slip-free run (non-tracking)-maintenance limit.

Severity: Critical

In LD 60 all looks good when I do SSCK 0. When I RCNT. I am still getting SLIPD on loop 7. Is there anyone that can please point me in the direction I need to resolve this problem? I have had help in the past with this clocking problem and sincerely express my thanks.

 

[KCFLHRC]

Lets see a print out of the DDB in LD 73

 

[rjtripp]

LD 73
REQ PRT
TYPE DDB

CC0 3
PREF CC0 3
SREF CC0 7
CTRR NO

TRSH 00
RALM 128
BIPC 0
LFAC 0
BIPV 3 2
SRTK 5 30
SRNT 15 3
LFAL 1 511
SRIM 1
SRMM 2
ICS

 

[KCFLHRC]

So how was the clocking done before? The whole story. Or is this all new programming? I think I would disable loop 7 and enable again and if loop 7 is a TMDI I would FDL that TMDI. Do you also have a daughter board on Loop 7? If you do it's not needed. One clock controller per cabinet.

 

[rjtripp]

I am not sure what the whole story is of the clocking issue. From all the work I have done on this system I know there was a bonehead of a technician that came before me! No new programming. I was tasked to correct the clocking problem when I found out that there was no clock controller daughter board (CCDB) on any TMDI card in the system. I then installed the CCDB on loop 3. I did that because according to the LD 73 PRT loop 3 is the primary clock loop. Loop 7 is secondary and does not have a CCDB. There is only one CCDB as needed per CPU. Thanks KCFLHRC.

 

[KCFLHRC]

If loop 7 is taking slips I think I would disable that TMDI and FDL it to see if that corrects the issue. Also post a print out of SSCK in LD 60

Thanks

 

[kstaff22]

another thing to consider is where the Ts are going?

what is loop 3 clocking off of?---telco---a voip gateway?
same thing with loop 7--------what is that connected to?

 

[KCFLHRC]

If loop 3 isn't taking any clocking errors then the issue is definitely not with the clocking source but more possibly something wrong with loop 7. Loop 7 will pull the clock reference from loop 3

 

[rjtripp]

>LD 60
DTI000
.SSCK 0
ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - LOCKED TO SLOT 3
PREF - 3
SREF - 7
AUTO SWREF CLK - ENBL
NO ERROR

IP DB PORT 1 DSBL
IP DB PORT 2 DSBL
IP DB PORT 3 DSBL
IP DB PORT 4 DSBL
CALL SERVER CLK SRC: CC

I am still getting SLIPD on loop 7. I think my next course of action is to do the TMDI thing on loop 7. If there is a problem with that card, they have spares. After the CCDB install the clock went into free run. I had a bear of a time getting loop 3 to enable. I had to reset and self test several times before I could force download and get the card enabled. The CC then automatically locked to loop 3 without a problem.

 

[KCFLHRC]

There is also a RST command for the TMDI that I have had to use in the past when all else failed.

 

[rjtripp]

Yes, I had to use the RST TMDI command several times on loop 3 to get it to enable. Back to loop 7, do you guys think I should try to disable and enable the TMDI SW and see if it needs to adjust to it's new reality? As far as what history I am getting from IT, that system has not had clocking (CCDB) for at least 6 + months. I just started working with this customer for 3 months. The IT boss has taken me in as there Nortel tech and I don't want to disappoint.

 

[KCFLHRC]

I think there could be some issues with loop 7. If taking the TMDI completely down, unseating it and then bringing it back into service doesn't fix the issue I would do a sysload. Or power the whole thing down and then back up which essentially is a sysload on the 11. What processor do you have?

 

[rjtripp]

If taking the TMDI completely down, unseating it and then bringing it back into service doesn't fix the problem, I would try a manual INI (warm start) before I would try a sysload (cold start). I am not sure what processor I have. Is there a command that will tell me that?

 

[bignose21]

I think you still need to answer kstaff2 what are both links connected to? (PSTN, VOIP Gateways, Other Terminal equipment, etc.)

The thing is clocking could be good but if whatever Loop 3 is connected to is getting a a bad clock then there may be no issue with Loop 7 just the fact that you are referencing a bad source.

 

[rjtripp]

Don't know 100% what the PRI source is. I have asked IT for a list of circuit numbers and what loops they are connected to. I have also asked if any Nortel TMDI cards are connected to there network. I have had no response from that request. From the feedback I am getting, the Nortel switch is low on there priority.

 

[rjtripp]

From my past experience I tend to agree with KCFLHRC. "If loop 3 isn't taking any clocking errors then the issue is definitely not with the clocking source

 

[yyrkroon]

remove the secondary ref in ccdb

 

[rjtripp]

I now have 2 possible avenues to resolve this issue. I don't want to change any programming at this time. I would like to get a second opinion on removing the SREF in DDB. Also I would like to get an answer to that question KCFLHRC asked. "What processor do you have?" I am not sure. Is there a command that can answer that, or is it visual?

 

[bignose21]

Removing the SREF will not stop loop 7 slipping BTW an example of what i am trying to get at. We have a lot of sites that are connected:



PSTN-----|---UX Gateway---|PABX
|---UX Gateway---|

Reason for this the bulk of the calls route off from the Sonus UX Gateways (2 or more per site) to Microsoft Lync/Skype and then the PABX has a PRI link to each Gateway. Now say my PABX Primary clock is UX1 and secondary is UX2. If the PSTN link to UX1 fails then the PABX clock continues to source its clock from UX1 even though it is in Free Run, so after a bit the link to UX2 will fail even though that is the Gateway with the good clock.

So in your case if whatever Loop 3 is connected to has lost its clock source you will quite happily sync to it and now also have a bad source. So like i say Loop 7 may actually be good and the problem lies on the other end of Loop 3. But to figure this out you need to know what you are connected to and the status of those devices.