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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Balashov > Sent: Wednesday, 19 September 2007 11:00 AM > To: Chris Hale > Cc: [email protected] > 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 > > [EMAIL PROTECTED] > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- ------------------ Chris Hale [EMAIL PROTECTED] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
