[cisco-nas] Slips
Aaron Leonard
Aaron at cisco.com
Wed Oct 10 14:09:48 EDT 2012
I suppose it is possible that a DACS could introduce enough jitter into
the signal to keep the other system from deriving clock from the line.
This is not a problem in the general case though.
------------------------------------------------------------------------
On 10/9/2012 9:31 PM, jfmays at launchpad.win.net (Joe Mays) wrote:
> It has been suggested that if those circuits go through a DAX, the
> clocking signal may not be making it to the other system.
>
> ----- Original Message -----
> *From:* Aaron Leonard <mailto:Aaron at cisco.com>
> *To:* Joseph Mays <mailto:mays at win.net>
> *Cc:* cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>
> *Sent:* Tuesday, October 09, 2012 7:00 PM
> *Subject:* Re: [cisco-nas] Slips
>
> The 5400 has only one clocking domain. So, if you are getting
> clock from slot 6 port 0, then this is the time source for the
> whole TDM bus. So, all other T1s on the 5400 will be synchronized
> to that source, and anything that takes clock from those T1s
> should be synchronized.
>
> http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a008014f8a6.shtml
>
> That's why I suspect that the system on the other side of T1 6/1
> is not actually taking clock from the line. Maybe it's free
> running or maybe it's taking clock from something else.
>
> Aaron
>
> ------------------------------------------------------------------------
>
> On 10/9/2012 2:46 PM, mays at win.net (Joseph Mays) wrote:
>> I would like to change port 6/1 to clocking internal, but I can't
>> find any way change the clocking on an individual t1 port
>> controller to internal. Am I missing something?
>>
>> ----- Original Message -----
>> *From:* Joseph Mays <mailto:mays at win.net>
>> *To:* Aaron Leonard <mailto:Aaron at cisco.com>
>> *Cc:* cisco-nas at puck.nether.net
>> <mailto:cisco-nas at puck.nether.net>
>> *Sent:* Tuesday, October 09, 2012 4:48 PM
>> *Subject:* Re: [cisco-nas] Slips
>>
>> Thank you for your response.
>> Show tdm clocks shows the AS5400 is using the circuit in port
>> 6/0 for primary clocking.
>> Primary Clock:
>> --------------
>> System primary is slot 6 port 0 of priority 1
>> TDM Bus Master Clock Generator State = NORMAL
>> Backup clocks for primary:
>> Source Slot Port DS3-Port Priority Status State
>> -------------------------------------------------------------
>> Trunk 1 1 YES 2 Good Configured
>> Trunk 1 2 YES 3 Good Configured
>> Trunk 1 3 YES 4 Good Configured
>> Trunk 1 4 YES 5 Good Configured
>> Trunk 1 5 YES 6 Good Configured
>> Trunk 6 1 NO 213 Good Default
>> Trunk 1 28 YES 202 Good Default
>> Trunk 1 27 YES 203 Good Default
>> Trunk cards controllers clock health information
>> ------------------------------------------------
>> CT3 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
>> Slot Port Type 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7
>> 6 5 4 3 2 1
>> 1 0 T3 G G G B B G G B B G B G B B B B B B B B B B
>> B G G G G G
>> We had considered the possibility that the problem might be
>> coming from the mux that everything was passing through. I
>> rewired the pinouts from telco in order to connect them
>> directly to a t1 port on the AS5400 (Controller 6/1), rather
>> than passing them through the mux and coming across a channel
>> on the t3. It works, but the slips are exactly the same.
>> ArmoryPl-AS5400#show controller t1 6/1
>> T1 6/1 is up.
>> Applique type is Channelized T1
>> Cablelength is long gain36 0db
>> Description: Leonard Brush MUX Bypass
>> No alarms detected.
>> alarm-trigger is not set
>> Version info of slot 6: HW: 768, PLD Rev: 1
>> Framer Version: 0x8
>> Manufacture Cookie Info:
>> EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x02,
>> Board Hardware Version 3.0, Item Number 73-3996-03,
>> Board Revision A0, Serial Number JAB044106K3,
>> PLD/ISP Version <unset>, Manufacture Date 11-Oct-2000.
>> Framing is ESF, Line Code is B8ZS, Clock Source is Line.
>> Data in current interval (638 seconds elapsed):
>> 0 Line Code Violations, 0 Path Code Violations
>> 54 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0
>> Degraded Mins
>> 54 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
>> 0 Unavail Secs
>> Right next to it is the trunking circut plugged into 6/0, it
>> runs fine, no slips. I would like to change 6/1 to internal
>> clocking, btw, so that it should be following the clock that
>> is being derived on 6/0, but can't find anyway to change that
>> on the t1 ports. So as it stands right now, both 6/1 and the
>> customer router on the other end of that t1 are set to
>> clock-source line, with no mux between them. And getting slips.
>> ----- Original Message -----
>> From: "Aaron Leonard" <Aaron at cisco.com <mailto:Aaron at cisco.com>>
>> To: "Joseph Mays" <jfmays at launchpad.win.net
>> <mailto:jfmays at launchpad.win.net>>
>> Cc: <cisco-nas at puck.nether.net
>> <mailto:cisco-nas at puck.nether.net>>
>> Sent: Tuesday, October 09, 2012 3:21 PM
>> Subject: Re: [cisco-nas] Slips
>>
>> > Joe,
>> >
>> > Sounds like, conceptually, you've set things up right. I
>> would
>> > doublecheck on the customer routers to make sure that they
>> really are
>> > taking clock from the right T1 line.
>> >
>> > On the 5400, you should be using "tdm clock priority" to
>> set the clock
>> > source, and "show tdm clocks" to validate the clocking.
>> >
>> http://www.cisco.com/en/US/docs/ios/12_3/dial/command/reference/dia_s6g.html#wp1140246
>> >
>> > Aaron
>> >
>> > ----
>> >
>> > On 10/9/2012 8:43 AM, jfmays at launchpad.win.net
>> <mailto:jfmays at launchpad.win.net>(Joseph Mays) wrote:
>> >> It occurs to me that there is an assumption built into
>> this that is
>> >> unproven. Does setting the AS5400 to internal clocking on
>> the T3 cause it to
>> >> provide clocking for the T1's on the T3? We have assumed
>> that it does. If
>> >> not, how do we tell it to provide an outgoing clock signal
>> for the T1's on
>> >> the T3?
>> >>
>> >> ----- Original Message -----
>> >> From: "Joe Mays" <mays at win.net <mailto:mays at win.net>>
>> >> To: "cisco-nsp" <cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>>;
>> <cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>>
>> >> Sent: Tuesday, October 09, 2012 12:57 AM
>> >> Subject: [cisco-nas] Slips
>> >>
>> >>
>> >>> We have an AS5400 that we are using to provide PRI's to
>> customers. It has
>> >>> the following circuits coming into it from the Telco (AT&T).
>> >>>
>> >>> 5 Trunking circuits that come across T1 ties into a t3
>> mux, and then are
>> >>> then delivered to a T3 port on the AS5400. ! trunking
>> circuit that is
>> >>> connected into a T1 card on the AS5400. Several circuits
>> to customers that
>> >>> are delivered out of the T3 through the mux to T1 tie
>> pairs through AT&T,
>> >>> and some of which go through HDSL T1's that we provide.
>> >>>
>> >>> We have clocking set up thusly. The T1 port that has the
>> trunk line in it
>> >>> (Serial6/0) is set to clock source line, to get clocking
>> from AT&T.
>> >>> The TDM clock priority on AS5400 is set to Serial6/0.
>> >>> The T3 that has all the other T1's is set to clock source
>> internal, on the
>> >>> assumption that the internal clock on the AS5400 should
>> now be
>> >>> synchronizing to the trunk line coming in on 6/0. So all
>> the T1 channels
>> >>> on the T3 should be following the Cisco clock.
>> >>> The mux is set to clocking is set on the t3 to clock
>> source line, to get
>> >>> clocking from the T3 coming from the AS5400.
>> >>> The customers at the end are all set to clock source line.
>> >>>
>> >>> None of the trunks is having slips, but several of the
>> AT&T customers are
>> >>> showing a slip every 10 seconds or so. The clocking chain
>> we have set up
>> >>> seems logical to me. Is there something I'm missing? Why
>> would the
>> >>> customers be having slips.
>> >>>
>> >>> We asked AT&T to monitor one of the lines that we are
>> seeing slips on.
>> >>> They watched it for a bit and said no slips are
>> occurring, though I am
>> >>> seeing them both on the AS5400 and on the Customer
>> router. They are
>> >>> performing a more indepth test now.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> cisco-nas mailing list
>> >>> cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>
>> >>> https://puck.nether.net/mailman/listinfo/cisco-nas
>> >>
>> >> _______________________________________________
>> >> cisco-nas mailing list
>> >> cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>
>> >> https://puck.nether.net/mailman/listinfo/cisco-nas
>> >>
>> > _______________________________________________
>> > cisco-nas mailing list
>> > cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>
>> > https://puck.nether.net/mailman/listinfo/cisco-nas
>> ------------------------------------------------------------------------
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>
> ------------------------------------------------------------------------
> _______________________________________________
> cisco-nas mailing list
> cisco-nas at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-nas/attachments/20121010/24ea015c/attachment-0001.html>
More information about the cisco-nas
mailing list