I heard this story more than once and it got me thinking about a couple of things. The first thought revolves around how the IE voice exam is graded. For the IE voice it is a hybrid method of running automated scripts and proctor review. Since a portion of the grading is automated, you have to ensure you are very specific. If you overlook or miss any aspect of a question, no matter how small the miss, you will get zero points.
Another thought was about the relationship between requirements in the lab. While the lab is made up of individual questions, it is supposed to act as a seamless solution once you complete all tasks. This means that when you work on one question, you have to ensure it does not violate the requirements of another question.
Enough of my pondering, let's get to the point. While I believe it is remotely possible that an exam is unfairly or inaccurately graded, I believe it is more likely that small oversights will derail your efforts. The first "I shoulda' checked that" tip of the series: Checking Network Clocks.
The Scenario...
You will definitely have a requirement to set up at least three separate trunks to the PSTN. These will typically be T1 or E1 PRI trunks and you will most likely need to recover clock from the pseudo-PSTN in the lab. You can configure and stand up a PRI connection to the pseudo-PSTN without configuring clock sources. If you overlook this physical layer config then you will most likely lose points.
Let's take a look at an example. We have provisioned a T1-PRI on controller T1 0/0/0. When we check our ISDN status, everything looks great. We are also able to place/receive calls. Our question said to set up a T1-PRI, make sure we can receive an ingress call to our IP phone extensions, and ensure we can call 911. All of those tests work as expected.
However, there is still something wrong:
[We check out our ISDN status] SiteA-RTR(config)#do sh isdn stat Global ISDN Switchtype = primary-ni %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply ISDN Serial0/0/0:23 interface dsl 0, interface ISDN Switchtype = primary-ni L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x800000FF Number of L2 Discards = 0, L2 Session ID = 15 ! ! [Next, check out our clocks] SiteA-RTR(config)#do sh network-clocks Network Clock Configuration --------------------------- Priority Clock Source Clock State Clock Type 10 Backplane GOOD PLL Current Primary Clock Source --------------------------- Priority Clock Source Clock State Clock Type 10 Backplane GOOD PLL
In the above output, we see that we appear to have a healthy T1 PRI connection (State = MULTIPLE_FRAME_ESTABLISHED). However, as shown in the "show network clocks" output, we are recovering clock from the backplane. This is not ideal and I think it would lead to a big goose egg for the original question. Not to mention, the above scenario can lead to errors on the line, as the following controller output shows:
SiteA-RTR(config-voiceport)#do sh controller t1 0/0/0 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: 20080918, FPGA: 13, spm_count = 0 Framing is ESF, Line Code is B8ZS, Clock Source is Line. CRC Threshold is 320. Reported from firmware is 320. Data in current interval (483 seconds elapsed): 3 Line Code Violations, 4 Path Code Violations 207 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 206 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 109 Unavail Secs
To remedy this issue (for our example circuit), use the command:
network-clock-select 1 t1 0/0/0
The Take Away...
You may be thinking that my solution is obvious and everyone should know this. However, if you troll through the various IE forums you will see people ask why they got zero points for the gateway section. Some of these folks post their configs and in a lot of those configs you don't see the network-clock-select command.
You want to make sure you don't miss an obvious (maybe even "assumed") configuration requirement in your haste to get that T1 or E1 up and taking calls. Make sure you configure clocking and you should always use the show network-clocks command to verify your work. You may also want to clear your controller counters (e.g clear controller t1 0/0/0) and check the controller to make sure the line isn't taking hits (e.g. show controller t1 0/0/0).
What we want to see:
SiteA-RTR#show network-clock Network Clock Configuration --------------------------- Priority Clock Source Clock State Clock Type 1 T1 0/0/0 GOOD T1 10 Backplane GOOD PLL Current Primary Clock Source --------------------------- Priority Clock Source Clock State Clock Type 1 T1 0/0/0 GOOD T1 SiteA-RTR#show controller t1 0/0/0 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: 20080918, FPGA: 13, spm_count = 0 Framing is ESF, Line Code is B8ZS, Clock Source is Line. CRC Threshold is 320. Reported from firmware is 320. Data in current interval (552 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
Thanks for reading. If you have time, post a comment!
Great post William. Thanks so much for this series and keep the posts coming!
ReplyDeletei will , great post just got a issue resolved for my client with this one, GW was misconfigured.
ReplyDeletei just dont get it why on the show controller t1 0/0/0 says:
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
on my issue here, i had a suspicious regarding the E1 clock missing on the network-clocks, like the output you pasted above the only clock source was the backplane, however also like the output you pasted the clock source is the line and not the back plane....
i keep wondering why it says line and not backplane..
thanks for the info ... my issue here is fixed..
symptoms were, delay to complete calls