Friday, November 30, 2012

CCIE-V "I Shoulda' Checked That" Tip #1: Network Clocks

This blog series is inspired by a forum thread I found where a fellow CCIE-V candidate was really fired up about a recent exam attempt. He had finished the exam in around 6 hours and had 2 hours to double and triple check everything. He was very confident about this sitting and was sure everything was operating as expected. Unfortunately, the grade came back "Fail". Obviously, he wasn't too happy about that and was convinced that everything was working when he left the testing facility.

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!

2 comments:

  1. Great post William. Thanks so much for this series and keep the posts coming!

    ReplyDelete
  2. i will , great post just got a issue resolved for my client with this one, GW was misconfigured.

    i 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

    ReplyDelete