At the end of this month, the long beloved 2800 series voice gateways go end of support. If you find yourself finally getting around to replacing these boxes with the 4000 series voice gateways, you’ll be happy to hear that transitioning PRIs from one to the other is relatively painless for voice work*.
I found it did take me a few minutes to hone in on the shiny new syntax for the clocking commands, so here’s a quick overview of what you’ll need to know.
We’re all pretty used to the standard “network clock participate, blah, blah, blah…” command paired with the “network clock select something-or-other…” command to keep those slip seconds on the T1 controller away.**
With the 4Ks, you need something similar, but of course, they couldn’t just leave the syntax the same. Instead you need to use something like this, of course using the slot numbers that your T1 card is installed in:
network-clock synchronization automatic
no network-clock synchronization participate 0/1
a previous version of this post had these commands:
network-clock input-source 1 controller t1 0/1/0
network-clock sync participate 0/1
but a very smart TAC engineer alerted me to bug ID CSCvb01800 which has to do with how the NIM is included, or rather, not included in the clocking. This changes the configuration in two important ways – one, forget the input-source command. Secondly, enter the no network-clock synchronization participate 0/1 command even though you don’t see network-clock synchronization participate 0/1 in the configuration. This command is the default and not visible, even in the show run all. If you followed my previous version of this post’s commands, you simply need to do a no network-clock input-source 1 controller t1 0/1/0 and a no network-clock sync participate 0/1.
And don’t forget to add “clock source line primary” on the controller port – you didn’t typically need to explicitly set this on the 2800s/2900s, but apparently the 4Ks need more hand holding and direct instructions.
controller T1 0/1/0
framing esf
clock source line primary
linecode b8zs
cablelength long 0db
pri-group timeslots 1-24
When you get this right, you should see some good news similar to this scroll across the screen – feel free to do a little happy dance:
*Sep 9 21:11:01.139: %NETCLK-6-SRC_ADD: Synchronization source T1 0/1/0 is added to T0 selection process.
And you can check your T1 clocking information when you bring the circuit up with this handy little command:
#show network-clock sync
Symbols: En – Enable, Dis – Disable, Adis – Admin Disable
NA – Not Applicable
* – Synchronization source selected
# – Synchronization source force selected
& – Synchronization source manually switched
Automatic selection process : Enable
Equipment Clock : 2048 (EEC-Option1)
Clock Mode : QL-Disable
ESMC : Disabled
SSM Option : 1
T0 : T1 0/1/0
Hold-off (global) : 300 ms
Wait-to-restore (global) : 300 sec
Tsm Delay : 180 ms
Revertive : No
Nominated Interfaces
Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx
Internal NA NA/Dis 251 QL-SEC NA NA
*T1 0/1/0 NA NA/Dis 1 QL-SEC NA NA
My apologies for a messy looking post, but due to the bug ID mentioned before, the verifications I mentioned in the previous version of this post change. For now, I am leaving the prior text in with strike-through, so anyone who read the previous post can see the changes.
Using the commands adjusted for the bug ID, you see this instead:
#show network-clock sync
Symbols: En – Enable, Dis – Disable, Adis – Admin Disable
NA – Not Applicable
* – Synchronization source selected
# – Synchronization source force selected
& – Synchronization source manually switched
Automatic selection process : Enable
Equipment Clock : 2048 (EEC-Option1)
Clock Mode : QL-Disable
ESMC : Disabled
SSM Option : 1
T0 : Internal
Hold-off (global) : 300 ms
Wait-to-restore (global) : 300 sec
Tsm Delay : 180 ms
Revertive : No
Nominated Interfaces
Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx
*Internal NA NA/Dis 251 QL-SEC NA NA
After cutting over to the new gateway, you can check for slip seconds on the line using the old standard “show controller T1 0/1/0” – but be sure you clear the counters after plugging in the circuit, since there are always a few slip seconds reported when first plugging in the circuit.
After resetting the counters, check that the slips stay at zero.
#show controller t1 0/1/0
T1 0/1/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary.
Data in current interval (566 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
[output truncated]
Bonus material – the other strange syntax issue I hit with the 4Ks was bug ID CSCup86596 and the command “isdn incoming-voice voice” command wouldn’t take under the signaling channel configuration – the workaround is epic in its vagueness, noting that “the functionality is there and will work” even though you cannot enter the command. So, yeah, typical voice shenanigans…
More bonus material – I was made aware by the previously mentioned very smart TAC engineer, that if you are looking into RTP-NTE (RFC 2833) DTMF issues on a 4K, you are going to need packet captures, the debug voip rtp sess name doesn’t do the trick. I haven’t had to face this one yet, but hopefully that little bit of information will save you some time if you do.
*voice is pain, any one who tells you otherwise is trying to sell you something 😉
**to set clocking for PRIs on 2800s/2900s, typically you use something like these two commands, depending on which slot the WIC card is plugged into. If you are seeing slip errors, you should check for these commands:
network-clock-participate wic 1
network-clock-select 1 T1 0/1/0
Published 10/21/2016
Amy Engineer 
Thanks for this post. I started working with 4451’s this year. I am working on a gateway know where I am having a L2 issue. On previous Gateways I only added the network-clock synchronization automatic command. And have had no issue. On this gateway, I am having an issue. I have 2 controllers, 2 pris, have slips on both. Any thoughts, suggestions?
I know one of the new features of the 4Ks is that you can have independent clocking per port, so you could have PRIs from two different carriers now. I’m guessing to allow for that magic to happen, there’s an additional step or two when configuring clocking for multiple PRIs. Looking for a sample config, will post a link when I find one.
I appreciate it. Same Telco. I was looking at one of my other sites that ones 3 pri’s. This issue does not happen. Did a stare and compare on both. I am going to reboot the router during non production. I also reviewed cisco documentation.
Cool! Let me know what you find out – definitely curious. I bookmarked this page for clock sync information for the 4Ks, but I’m sure you’ve already seen it. http://www.cisco.com/c/en/us/td/docs/routers/access/4400/feature/guide/isr4400netclock.html
Emily, I made some updates to this post that might explain some of what you are seeing, not sure if they are related but I am thinking it could be…
HI Amy, Thank you for the updated and research on your part. I did issue the no network-clock synchronization participate 0/1, you can imagine my anticipation as I repeated issued the show isdn status command. However, unfortunately, it did not fix my issue. I did reset my counters after issuing the command.
I have two pris/interfaces. Do you think it would safe to say, if I were impacted by this bug, both of my interfaces would be having issues?
I see the below when I debug isdn a921
Oct 31 11:50:27.573: ISDN Se0/1/1:23 Q921: User TX -> SABMEp sapi=0 tei=0
Oct 31 11:50:28.574: ISDN Se0/1/1:23 Q921: User TX -> SABMEp sapi=0 tei=0
I’ve been engaging the Telco. When I first cut over this site, I found one of the PRI’s was down and no one had noticed. My operating PRI will work in either interface. But this second one will not. Telco Tech says it tested good. But I am wondering if the provisioning is good at this point.
Or do you think it is worth calling TAC at this point and still work the bug issue?
I would follow up with telco and be sure they didn’t deactivate your second PRI. I have just dealt with that. An overflow PRI was down due to a bad card on my side, they didn’t notify anyone, I changed the card, and it still wouldn’t come up even though telco said it tested good. They eventually found it had been deactivated. I’d also work with TAC, though, because my hunch is there’s something different or broken about clocking with two PRIs and the NIM module clocking.
That is my logic as well. I’ll be sure to post an update when I get to my conclusion.
Thank you very much. Helped me resolve my issue with slips.
I’m being u realize that “Typical Cisco shenanigans” should now become synonymous with their product line, especially in Voice.
Have you written a tribute to the 7965 G yet? Those phone take a licking but truly keep on ticking. Other than the 2800s, this was the last great hardware Cisco made that revolutionized the VoIP market and it deserves its own eulogy some day.
TAC had be upgrade to their latest recommended version of the IOS. Below is what I ended up with configured on my gateway. 2 PRI’s
network-clock synchronization automatic
network-clock input-source 1 controller T1 0/1/1
network-clock input-source 2 controller T1 0/1/2
Calling the clock source line Primary and secondary on the controllers.
I also ran into the issue of adding “isdn incoming-voice voice” to the interface. The command was rejected. But it eventually showed up on its own = Shenanigans.
I deployed new hardware to this site, and configured it similarly to the old gateway. But we’ve had problems with call quality and call set up. I am still working with TAC to isolate the source of static during in bound calls. However, on outbound calls intermittently I will see multiple attempts to set up. When I troubleshoot with the Telco, they will only see the one (the successful one) setup message from us.
Wow – very interesting. What version of IOS are you on now? Keep me posted on the multiple call attempts – I have only seen that on FXO lines that had sustained physical damage, it was *weird*
“bootflash:isr4400-universalk9.03.16.04b.S.155-3.S4b-ext.SPA.bin and will do. We inserted a loopback facing the gateway. It tested clean. Telco inserted a loopback facing their equipment. Tested Clean. Only one thing between those two.
Annnnnnd I’m done. So far 🙂 In short, we ran two new Sheilded Cat 6 and it has resolved this issue.I am remote to the site. I was able to get someone to check out the cabling situation between the smartjack and my equipment. There was no pair separation leading to interference. Turns out from the smart jack the cabling was running to an old 66 block, then to a another patch panel then to the gateway. New cables = no static on inbound calls, no inconsistent behavior, no failed set up attempts outbound 🙂
That is really interesting. The static issues and echo issues I’ve seen before have all been wiring as well. Thanks for updating this! Really good info to have!
Emy & Emily :- I am following what is being discussed here. We deployed 4331 with FXO cards, 8 Lines with two Combo 2fs/4fxo card. and site started complaining that they have intermittent call quality issues both incoming and outgoing ( Echo, Crackling, Staticky). i never thought that there were any known issues with FXO cards
IOS:- bootflash:/isr4300-universalk9.03.16.02.S.155-3.S2-ext.SPA.bin
Also these Analog Lines are provisioned by AT&T ” Business in a Box IP Flex” service. So i was inclined to believe that these are AT&T calling issues.
In the work around for bug CSCvb01800 it says to use clock source network and not clock source internal. In your post you say to use clock source line primary. Is there a reason you didn’t use clock source network?
I based my configuration on a conversation with a TAC engineer familiar with the issue that the bug ID was based on, something to do with clock source internal being used for channel-groups now, clock master from NIM. He didn’t go too deep but indicated something about no backplane for ISDN clocking.
Hi Amy,
Thanks for the post.
I am just wondering if anyone has a positive experience with the new IOS as mentioned prior – 3.16.4bs.
Currently we have 1 PRI at a particular location that is having weekly hard downs on the T1 interface.
RTR-01#show controllers t1
T1 0/1/0 is down.
Applique type is Channelized T1
Cablelength is long gain36 0db
Description: T1 0/1/0 (Greenville PRI)
Transmitter is sending remote alarm.
Receiver has loss of signal.
alarm-trigger is not set
We have a 4331/NIM-2CE1T1-PRI on IOS 03.13.06.S with the following config.
!
controller T1 0/1/0
framing esf
clock source line primary
linecode b8zs
cablelength long 0db
pri-group timeslots 1-24 voice-dsp
!
network-clock synchronization automatic
network-clock input-source 1 controller T1 0/1/0
!
Our PRI drops weekly and the service provider refuses to acknowledge a problem with their PRI router, but a power cycle of their device brings the T1 back up…..so I still cannot exclude them, but dealing with AT&T makes you want to pull your hair out.
Was going to add the commands as suggested, but then saw the post of upgrading the IOS and omitting these commands:
no network-clock input-source 1 controller t1 0/1/0
no network-clock sync participate 0/1
Looking for any suggestions.
Thanks so much for posting this. We upgraded all of our 23 locations to 4k’s from 28/29 series routers about 6 months ago. I’ve had locations using 1 provider with no problem and with Comcast PRI’s it’s been nothing but a mess. This “hidden command” fixed the slips. They are no more. Thanks again!!
As soon as entered the “no network-clock input-source 1 controller t1 0/1/0” command the slip seconds stopped but again wen tried to enter “no network-clock sync participate 0/1” slip seconds started. Just a heads up in case