[c-nsp] MLPPP/T1 problems

Joe Freeman joe at netbyjoe.com
Wed Sep 19 09:50:44 EDT 2007 

Generally any circuit that passes through the telco will be muxed or DACS'd
somewhere. This is generally where the telco applies timing they derive from
either a CDMA or - more likely these days - a gps clock.

I always start with line timing on my circuits, and roll one end back to
internal clock if I notice slips.

Something to note as well, timing issues usually show up as slips when the
circuit is normalized, which disappear when the circuit is looped back.

Also, I always run an all zero's or all one's in addition to a qasi pattern
whenever I loop a circuit. The all zero's or all one's will throw errors on
a circuit that's setup for AMI, or a circuit that has some segment setup as
AMI, which happens more often than most people think.

A circuit that's mixed AMI and B8ZS will take random errors, may or may not
work at certain traffic levels, and the errors generally disappear when
looped if all you run is a qasi pattern.

Joe

On 9/19/07, Chris Hale <chale99 at gmail.com> wrote:
>
> Thanks everyone for the ideas.  I worked with the telco last night and had
> them loop the circuit from the far end CSU, and ran BER tests for 5
> minutes
> without an error.  Since these are p2p circuits, the telcos don't provide
> clocking - is this a correct assumption?  One end of the circuit should
> provide clocking, and the other should listen to line for clocking -
> correct
> or not?  This is the way I have our other 2 dozen T1s that are running
> fine.
>
> I'll work with the customer to have them check their extended demarc and
> equipment.  It's just strange that it happened to all 4 T1s at the same
> time.
>
> Chris
>
> On 9/19/07, Daniel Hooper <dhooper at emerge.net.au> wrote:
> >
> > Hi,
> >
> > I just noticed the slipped secs on your controller and the fact your
> > running off an internal clock. Clock source line maybe if their's a mux
> > or something in the middle providing clocking?
> >
> > -Dan
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alex Balashov
> > Sent: Wednesday, 19 September 2007 11:00 AM
> > To: Chris Hale
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] MLPPP/T1 problems
> >
> >
> > Could it be a bad T1 controller?  Try swapping out the T1 card as well,
> > if
> > possible.
> >
> > Otherwise, I tend to agree;  the cause of your problems as visualised on
> >
> > the PPP layer most likely is reducible to underlying physical issues on
> > the physical framing layer.
> >
> > On Tue, 18 Sep 2007, Chris Hale wrote:
> >
> > > All -
> > >
> > > We have a 4xT1 MLPPP set up with a customer and yesterday it started
> > giving
> > > us problems.  For some reason, our side is sending a termreq when the
> > LCP
> > > session is set up, and PPP starts to come up:
> > >
> > > Sep 18 14:04:02.585 EDT: Se5/5:0 LCP: State is Open
> > > Sep 18 14:04:02.585 EDT: Se5/5:0 PPP: Phase is VIRTUALIZED [0 sess, 1
> > load]
> > > Sep 18 14:04:02.585 EDT: Se5/5:0 PPP: Phase is TERMINATING [0 sess, 1
> > load]
> > > Sep 18 14:04:02.585 EDT: Se5/5:0 LCP: O TERMREQ [Open] id 234 len 4
> > > Sep 18 14:04:02.589 EDT: Se5/5:0 LCP: I TERMACK [TERMsent] id 234 len
> > 4
> > > Sep 18 14:04:02.589 EDT: Se5/5:0 LCP: State is Closed
> > > Sep 18 14:04:02.589 EDT: Se5/5:0 PPP: Phase is DOWN [0 sess, 1 load]
> > >
> > > I originally thought I had a MRRU issue:
> > >
> > > Sep 18 14:03:40.525 EDT: Se5/5:0 LCP: O CONFREQ [Listen] id 215 len 30
> > > Sep 18 14:03:40.525 EDT: Se5/5:0 LCP: MagicNumber 0xB0158457
> > > (0x0506B0158457)
> > > Sep 18 14:03:40.525 EDT: Se5/5:0 LCP: MRRU 1500 (0x110405DC)
> > > Sep 18 14:03:40.525 EDT: Se5/5:0 LCP: EndpointDisc 1 br-1bp-bos-ma
> > > (0x13100162722D3162702D626F732D6D61)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: I CONFREQ [REQsent] id 110 len
> > 23
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MagicNumber 0x07CA49EA
> > > (0x050607CA49EA)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: EndpointDisc 1 Router
> > > (0x130901526F75746572)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: O CONFACK [REQsent] id 110 len
> > 23
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MagicNumber 0x07CA49EA
> > > (0x050607CA49EA)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: EndpointDisc 1 Router
> > > (0x130901526F75746572)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: I CONFACK [ACKsent] id 215 len
> > 30
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MagicNumber 0xB0158457
> > > (0x0506B0158457)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: MRRU 1500 (0x110405DC)
> > > Sep 18 14:03:40.529 EDT: Se5/5:0 LCP: EndpointDisc 1 br-1bp-bos-ma
> > > (0x13100162722D3162702D626F732D6D61)
> > >
> > > I fixed that even though both ends seemed to confack on (both?) the
> > MRRU of
> > > 1500 and 1524.
> > >
> > > I've done a BERT test through my local CSU/DSU with no errors, but
> > when I
> > > release the loopback, I start taking errors on the serial interface
> > that
> > > increment every few seconds:
> > >
> > > Serial5/5:0 is up, line protocol is down
> > >  Hardware is Multichannel T1
> > >  Description: QJR-0004
> > >  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
> > >     reliability 252/255, txload 1/255, rxload 1/255
> > >  Encapsulation PPP, crc 16, Data non-inverted
> > >  Keepalive set (10 sec)
> > >  LCP ACKsent, multilink Closed
> > >  Closed: CDPCP
> > >  Last input 00:00:14, output 00:00:00, output hang never
> > >  Last clearing of "show interface" counters 00:30:54
> > >  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> > >  Queueing strategy: fifo
> > >  Output queue: 0/40 (size/max)
> > >  5 minute input rate 0 bits/sec, 0 packets/sec
> > >  5 minute output rate 0 bits/sec, 0 packets/sec
> > >     1187 packets input, 26083 bytes, 0 no buffer
> > >     Received 0 broadcasts (0 IP multicast)
> > >     299 runts, 0 giants, 0 throttles
> > >     299 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> > >     1343 packets output, 35909 bytes, 0 underruns
> > >     0 output errors, 0 collisions, 0 interface resets
> > >     0 output buffer failures, 0 output buffers swapped out
> > >     0 carrier transitions
> > >  no alarm present
> > >  Timeslot(s) Used:1-24, subrate: 64Kb/s, transmit delay is 0 flags
> > >
> > > Here is the controller information:
> > >
> > > br-1bp-bos-ma#show controller t1 5/5 brief
> > > T1 5/5 is up.
> > >  Applique type is Channelized T1
> > >  Cablelength is long gain36 0db
> > >  Description: QJR-0004
> > >  No alarms detected.
> > >  alarm-trigger is not set
> > >  Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
> > >  Data in current interval (608 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
> > >  Total Data (last 18 15 minute intervals):
> > >     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, 16 Unavail
> > Secs
> > >
> > > We've opened a ticket with the telco who claims they test clean
> > between
> > > their demarks, but they are seeing a yellow alarm from us.
> > >
> > > The only thing I can think of is a bad cable from the telco demark to
> > our
> > > end.  Thoughts??
> > >
> > > interface Serial5/5:0
> > > description QJR-0004
> > > no ip address
> > > encapsulation ppp
> > > no fair-queue
> > > ppp authorization NOAUTH
> > > ppp multilink
> > > ppp multilink mrru local 1524
> > > multilink-group 6
> > > no clns route-cache
> > >
> > > controller T1 5/5
> > > framing esf
> > > clock source internal
> > > linecode b8zs
> > > channel-group 0 timeslots 1-24
> > > description QJR-0004
> > >
> > > Cisco IOS Software, 7200 Software (C7200-IK91S-M), Version 12.2(25)S7,
> > > RELEASE SOFTWARE (fc1)
> > > Technical Support: http://www.cisco.com/techsupport
> > > Copyright (c) 1986-2005 by Cisco Systems, Inc.
> > > Compiled Fri 28-Oct-05 09:12 by pwade
> > >
> > > ROM: System Bootstrap, Version 12.2(4r)B, RELEASE SOFTWARE (fc1)
> > > BOOTLDR: 7200 Software (C7200-BOOT-M), Version 12.0(24)S, EARLY
> > DEPLOYMENT
> > > RELEASE SOFTWARE (fc1)
> > >
> > > br-1bp-bos-ma uptime is 1 year, 9 weeks, 2 days, 18 hours, 56 minutes
> > > System returned to ROM by power-on
> > > System restarted at 00:45:13 EDT Sat Jul 15 2006
> > > System image file is "slot0:c7200-ik91s-mz.122-25.S7.bin"
> > >
> > > Thanks in advance.
> > > --
> > > ------------------
> > > Chris Hale
> > > chale99 at gmail.com
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> >
> > --
> > Alex Balashov
> > Evariste Systems
> > Web    : http://www.evaristesys.com/
> > Tel    : +1-678-954-0670
> > Direct : +1-678-954-0671
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
>
>
> --
> ------------------
> Chris Hale
> chale99 at gmail.com
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

More information about the cisco-nsp mailing list