Hipath 4K V7 PRI clock slipping

[jschnarkey]

Greetings,
I do not see an answer in the forum so I'll ask my question.
4K V7 with a PRI that is down. Telco just told me it is because of clock slipping errors on my end.
A display of refta below. No X in the supplied column. How do I fix this?
DIS-REFTA:CIRCUIT,1-22-9,ALL;
H500: AMO REFTA STARTED
+-------------------------------------------------------------------------+
| R E F E R E N C E C L O C K C I R C U I T S |
+--------------+---------+----------+---+------+------+------+-----+------+
| PEN | MODULE | DEVICE |PRI|ERROR |BLOCK |SUPP. |READY|SRCGRP|
| | | | | | | |BUT | |
| | | | | | | |ASYN.| |
+--------------+---------+----------+---+------+------+------+-----+------+
| 1-22- 9- 0 | DIUT2-M | S1COD | 75| 65535| N | | N | 22|
+--------------+---------+----------+---+------+------+------+-----+------+

AMO-REFTA-111 REFERENCE CLOCK TABLE
DISPLAY COMPLETED;
​

 

[Moriendi]

Remember that just because Telco says it - it doesn't make it so. "Telco" also means "big fat liar". If they are right, it could be hardware anywhere on your side, namely the DIU, the NCUI (as you are shelf 22), or even the cable. You could cha-refta and push those errors down to 0, see if they climb up again. If you have another IPDA shelf you could swap the NCUIs over (remember they will need reconfig of their IP addresses), or swap the DIU if you have another one (or maybe move the circuit to 1-22-9-1, if that circuit is free).

Hista might say something useful, maybe not. Probably a load of L2 errors which won't mean much when you decode, or at least nothing you'll be able to do anything about, without hardware. But, if the link is actually down, maybe you'll see some useful L1/alarm stuff.

Ideally here you need an ISDN tester to prove straight away in which direction the fault lies. Clocking errors from 4K are possible, but it would be unusual, at least it is in my experience. I'm assuming it's not config because I guess this was working fine until suddenly it wasn't. The errors could easily be coming from kit after the 4K and if so it's not your problem - did Telco send anyone to site to check that?

 

[jschnarkey]

Thanks Moriendi,
I have no idea if it was ever working. There are no DID's on it and it is bundled in a three PRI group for some outside faxing. A lot of extra channels here so I would not ever notice this if Century link did not find it yesterday during other trouble shooting.
I have cleared 9,142 slip errors an hour ago and see a couple new ones.
I also see in TDCSU that ins (in service activation of the unit) is set to no while the other two PRI's in the trunk group are set to yes.
I'm reaching out to our managed services guys. The HiPath guy is very familiar with our setup and worked for Siemens and then Unify before moving on.
​

 

[thepfy]

As others have said, sometimes getting a supplier to admit to a fault, particularly a clocking fault can be difficult.
Have had one supplier telling us we should be supplying the clock, rather than their side.

If there are multiple circuits from different suppliers then finding the best clock source for all the circuits can be tricky. Usually need to play with the clock priorities to find which is best.
As there are 3 PRI's it would be worth changing the priorities to see if fixes the issue.

 

[jschnarkey]

I have resolved the issue by moving the PRI DUIT2 from IPDA 22 to shelf 10. The cord was long enough to do this.
It seems IPDA 22 doesn't want to clock any more and we are not going to replace the NCUI.
Issue resolved. Because I have the bandwidth for the calls on this PRI bundle, there's no telling how long this was down. I only found it by working on another issue.

 

[Moriendi]

If you wanted to check when it went off (or if it ever worked), the hista logs are archived in /var/log/libvirt/qemu on the platform, so you might see something in there. Logging Managment in the Assistant will also search but you might prefer the raw hista, you can grep it.

Did you check the evtlog in NCUI for any errors, or try moving the DIU back to IPDA after it had been in service on the normal LTU? The config was 100% the same? It's an odd fault to get but must happen I suppose.

 

[jschnarkey]

No, I am probably not the guy for that though I would be interested in learning more about reading the logs.
We feel that since it is now up and taking traffic and we are rolling out a Cisco CUCM, we don't really care at this point and we did not even notice it to begin with.