[cisco-voip] PRI Clocking

[Jaquish, Bret]

With a PRI terminating on the router and using onboard PVDMs you need to sync the TELCO line clock with the internal PLL (network-clock-participate).  This gets the router/pvdms in sync with the clock coming from the provider.  Then choose the failover order (network-clock-select).  This looks right on your side.

If the provider is saying they see clock slips, look at the T1 controller statistics.  You can verify the clock source also.

Show controller t1 */*/* brief

If there are clock slips, it should show it.

T1 0/0/0 is up.
  Applique type is Channelized T1
  Cablelength is long 0db
  No alarms detected.
  alarm-trigger is not set
  Soaking time: 3, Clearance time: 10
  AIS State:Clear  LOS State:Clear  LOF State:Clear
  Version info Firmware: 20090408, FPGA: 13, spm_count = 0
  Framing is ESF, FDL is ansi, Line Code is B8ZS, Clock Source is Line Independent.
  CRC Threshold is 320. Reported from firmware  is 320.
  Data in current interval (296 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 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,
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs




-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike Thompson
Sent: Thursday, August 26, 2010 3:21 PM
To: Mike King
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] PRI Clocking

As go0se said, clocking for PRI is 100% from Telco.  If you're getting CRC, check patch cable, demarc extension, etc.  May be a bad smartjack as well.

Other than that, you're right on track

Sent from my phone, apologies for any typos.

On Aug 26, 2010, at 10:10 AM, Mike King <me at mpking.com> wrote:

> I'm assuming I didn't screw it up.
>
> network-clock-participate wic 0
> network-clock-select 1 T1 0/0/0
>
> Only PRI (and PRI VWIC) on the box.
>
>
>
> On Thu, Aug 26, 2010 at 11:00 AM, Go0se <me at go0se.com> wrote:
>> You should expect a PRI to ALWAYS ALWAYS ALWAYS run clean. Faxing is
>> especially susceptive to errors/failure across a PRI that has errors. And
>> you should ALWAYS clock off of the TELCO. That is ridiculous that they
>> suggested you provide an internal clock for a PRI. Do you have your network
>> clock participate and network clock select correct?
>>
>> Thanks,
>>
>> Go0se
>>
>> My blog:
>> http://atc.go0se.com
>>
>> --------------------------------------------
>> Help Hopegivers International
>> Feed the orphans of Haiti and India
>> http://www.hopegivers.org
>> --------------------------------------------
>>
>> -----Original Message-----
>> From: cisco-voip-bounces at puck.nether.net
>> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike King
>> Sent: Thursday, August 26, 2010 9:41 AM
>> To: Cisco VoIPoE List
>> Subject: [cisco-voip] PRI Clocking
>>
>> Just for someone to check my sanity.
>> I'm having the standard argument with Telco today  (We don't see anything,
>> it must be your equipment)
>>
>> I have a PRI that I've had complaints of dropped calls.
>>
>> I go an check the log on the 2921 router, and see this  (Across 3 different
>> dates, just one posted for brevity)
>>
>> 092856: Jul 30 2010 09:49:36.861 EDT: %MARS_NETCLK-3-HOLDOVER:
>> Entering Holdover for Controller T1 0/0/0
>> 092857: Jul 30 2010 09:49:38.613 EDT: %LINK-3-UPDOWN: Interface
>> Serial0/0/0:23, changed state to down
>> 092858: Jul 30 2010 09:49:47.113 EDT: %MARS_NETCLK-3-HOLDOVER_TRANS:
>> Holdover timer exceeded for Controller T1 0/0/0
>> 092859: Jul 30 2010 09:49:47.113 EDT: %MARS_NETCLK-3-CLK_TRANS:
>> Network clock source transitioned from priority 1 to priority 10
>> 092861: Jul 30 2010 09:57:23.612 EDT: %LINK-3-UPDOWN: Interface
>> Serial0/0/0:23, changed state to up
>> 092863: Jul 30 2010 09:57:32.112 EDT: %MARS_NETCLK-3-CLK_TRANS:
>> Network clock source transitioned from priority 10 to priority 1
>>
>> I also have CRC's on the serial0/0/0:23  (not a whole lot, just some)
>>
>> Telco of course says they've pulled PM's and see nothing. I've been pushing
>> the issue with my Telco Rep, and he's suggested that since it seems to be a
>> clocking issue (His words) that maybe we should set our PRI to internal
>> clocking.
>>
>> I reset the counters on my serial interface, and in the past 2 days, I've
>> recieved 1 CRC.  I've also not had the PRI drop any calls. (Or the whole PRI
>> drop, which is what I assume from those log messages)
>>
>>
>> I have another circuit at a different site, I reset it's counters at the
>> same time 48 hours ago, and It had this today (also I don't have any reports
>> of dropped calls, just problems faxing)..
>> 12 runts, 0 giants, 0 throttles
>> 32 input errors, 32 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
>>
>> My question is this:
>>
>> Is it Normal to have some number of CRC's on a PRI?
>> My personal experience is to ALWAY clock off Telco, and you should not have
>> any errors on my lines.  Am I wrong with this assumption?
>>
>> Mike
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Disclaimer Confidentiality Notice:  This e-mail, and any attachments
and/or documents linked to this email, are intended for the
addressee and may contain information that is privileged,
confidential, proprietary, or otherwise protected by law.  Any
dissemination, distribution, or copying is prohibited.  This
notice serves as a confidentiality marking for the purpose of
any confidentiality or nondisclosure agreement.  If you have
received this communication in error, please contact the
original sender.