[cisco-nas] Slips
Aaron Leonard
Aaron at cisco.com
Wed Oct 10 15:30:59 EDT 2012
The pri-group config is weird, but I would not think it's relevant.
My theory continues to be, until disproven, that the device that is on
the far side of the slipping span is not configured right.
------------------------------------------------------------------------
On 10/10/2012 12:21 PM, mays at win.net (Joseph Mays) wrote:
> Yeah. The DACS is not the problem though, because we have two circuits
> going through the DACS, in fact they are two circuits that are exactly
> the same, following the same path from our AS5400 through the telco to
> the same router (an IAD2400) at the same customer, one is getting
> slips one is not. Both go through the DACS. The only difference
> between them is that one has just a channel group for T1 service and
> the other has both a channel group and a PRI group. The one with just
> the channel group is plugged into the native T1 port on the IAD2400.
> The one with both is plugged into a card that will support multilple
> tdm groups on a card.
> On the AS5400....
> controller T1 1/0:22
> framing esf
> channel-group 0 timeslots 1-22 speed 64
> description Glass Doctor combo PRI and T1 1
> !
> controller T1 1/0:23
> framing esf
> channel-group 0 timeslots 1-22 speed 64
> pri-group timeslots 23-24
> description Glass Doctor combo PRI and T1 2
> The second one, on 1/0:23, gets slips about once every 10 seconds.
>
> ----- Original Message -----
> *From:* Aaron Leonard <mailto:Aaron at cisco.com>
> *To:* Joe Mays <mailto:jfmays at launchpad.win.net>
> *Cc:* cisco-nas at puck.nether.net <mailto:cisco-nas at puck.nether.net>
> *Sent:* Wednesday, October 10, 2012 2:09 PM
> *Subject:* Re: [cisco-nas] Slips
>
> 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
>
> ------------------------------------------------------------------------
> _______________________________________________
> 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/3dc47565/attachment-0001.html>
More information about the cisco-nas
mailing list