Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: VOIP

PRI Clocking

 

 

Cisco voip RSS feed   Index | Next | Previous | View Threaded


me at mpking

Aug 26, 2010, 7:41 AM

Post #1 of 8 (9236 views)
Permalink
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
https://puck.nether.net/mailman/listinfo/cisco-voip


me at go0se

Aug 26, 2010, 8:00 AM

Post #2 of 8 (9167 views)
Permalink
Re: PRI Clocking [In reply to]

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
[mailto:cisco-voip-bounces [at] puck] 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
https://puck.nether.net/mailman/listinfo/cisco-voip

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


lelio at uoguelph

Aug 26, 2010, 8:06 AM

Post #3 of 8 (9162 views)
Permalink
Re: PRI Clocking [In reply to]

geeez, next they'll be asking you to add " cablelength long 0db" to your config. ;)

---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)



From: "Go0se" <me [at] go0se>
To: "Mike King" <me [at] mpking>, "Cisco VoIPoE List" <cisco-voip [at] puck>
Sent: Thursday, August 26, 2010 11:00:15 AM
Subject: Re: [cisco-voip] PRI Clocking

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
[mailto:cisco-voip-bounces [at] puck] 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
https://puck.nether.net/mailman/listinfo/cisco-voip

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


me at mpking

Aug 26, 2010, 8:10 AM

Post #4 of 8 (9172 views)
Permalink
Re: PRI Clocking [In reply to]

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> 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
> [mailto:cisco-voip-bounces [at] puck] 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

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


me at go0se

Aug 26, 2010, 8:41 AM

Post #5 of 8 (9181 views)
Permalink
Re: PRI Clocking [In reply to]

You should be able to run a loopback diag and a BERT on your equipment to
test the vwic. If it tests ok then escalate. Have them do after hours
intrusive testing if possible.

I'm waiting for cisco to release their new line of VWIC-xTC&S-V2 vwics. They
will be much easier to troubleshoot. (TC&S = Tin Can & String)

VWIC-TC&S-V2 Troubleshoot guide:
1) check can
2) check string

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
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Mike King
Sent: Thursday, August 26, 2010 10:10 AM
To: Cisco VoIPoE List
Subject: Re: [cisco-voip] PRI Clocking

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> 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
> [mailto:cisco-voip-bounces [at] puck] 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

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


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


mthompson729 at gmail

Aug 26, 2010, 1:20 PM

Post #6 of 8 (9160 views)
Permalink
Re: PRI Clocking [In reply to]

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> 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> 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
>> [mailto:cisco-voip-bounces [at] puck] 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
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip

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


Bret.Jaquish at navistar

Aug 27, 2010, 7:56 AM

Post #7 of 8 (9147 views)
Permalink
Re: PRI Clocking [In reply to]

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 [mailto:cisco-voip-bounces [at] puck] 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> 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> 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
>> [mailto:cisco-voip-bounces [at] puck] 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
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
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.

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


me at mpking

Aug 27, 2010, 9:29 AM

Post #8 of 8 (9132 views)
Permalink
Re: PRI Clocking [In reply to]

Unfortuanlty, the String in the case is still Telco.

Is the loopback diag and the BERT service affecting? (I think so, but
I want to verify)

I haven't seen any slips... But then again, I was more than 24 hours
after the fact, so they had all aged out by then.

So in the last 24, I've gotten 1 more CRC, for a total of 2.

Last clearing of "show interface" counters 2d20h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 48 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
41005 packets input, 481747 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort

I'll continue to push my provider.

On Thu, Aug 26, 2010 at 11:41 AM, Go0se <me [at] go0se> wrote:
> You should be able to run a loopback diag and a BERT on your equipment to
> test the vwic. If it tests ok then escalate. Have them do after hours
> intrusive testing if possible.
>
> I'm waiting for cisco to release their new line of VWIC-xTC&S-V2 vwics. They
> will be much easier to troubleshoot. (TC&S = Tin Can & String)
>
> VWIC-TC&S-V2 Troubleshoot guide:
>        1) check can
>        2) check string
>
> 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
> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Mike King
> Sent: Thursday, August 26, 2010 10:10 AM
> To: Cisco VoIPoE List
> Subject: Re: [cisco-voip] PRI Clocking
>
> 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> 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
>> [mailto:cisco-voip-bounces [at] puck] 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
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

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

Cisco voip RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.