[c-nsp] MLPPP/T1 problems

Chris Hale chale99 at gmail.com
Wed Sep 19 09:29:06 EDT 2007


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


More information about the cisco-nsp mailing list