[c-nsp] MLPPP/T1 problems
OCOSA ListAcct
listacc at ocosa.com
Wed Sep 19 15:46:53 EDT 2007
Chris,
Have you tried clearing both your T1 Controller and PPP configurations,
then rebuilding one T1 at a time? Try Administratively shutting down
your others while you do so, one at a time turning back on. Was your 6
Meg Bonded T1 working before? Also have your customer check their side
to make sure they are using you as the clock source. You might advise
them to do the same as above.
Otis
Chris Hale wrote:
> We just finished running BER tests to include the customer's extended demark
> (which tested clean), and we're having the same problems.
>
> I just can't figure out why these T1's won't come up:
>
> Sep 19 13:55:16.202 EDT: Se5/5:0 PPP: Phase is ESTABLISHING, Passive Open [0
> sess, 1 load]
> Sep 19 13:55:16.202 EDT: Se5/5:0 LCP: State is Listen
> Sep 19 13:55:18.202 EDT: Se5/5:0 LCP: TIMEout: State Listen
> Sep 19 13:55:18.202 EDT: Se5/5:0 LCP: O CONFREQ [Listen] id 34 len 30
> Sep 19 13:55:18.202 EDT: Se5/5:0 LCP: MagicNumber 0xB53576BD
> (0x0506B53576BD)
> Sep 19 13:55:18.202 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> Sep 19 13:55:18.202 EDT: Se5/5:0 LCP: EndpointDisc 1 br-1bp-bos-ma
> (0x13100162722D3162702D626F732D6D61)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: I CONFREQ [REQsent] id 67 len 23
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MagicNumber 0x0CE9559D
> (0x05060CE9559D)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: EndpointDisc 1 Router
> (0x130901526F75746572)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: O CONFACK [REQsent] id 67 len 23
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MagicNumber 0x0CE9559D
> (0x05060CE9559D)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: EndpointDisc 1 Router
> (0x130901526F75746572)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: I CONFACK [ACKsent] id 34 len 30
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MagicNumber 0xB53576BD
> (0x0506B53576BD)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: MRRU 1524 (0x110405F4)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: EndpointDisc 1 br-1bp-bos-ma
> (0x13100162722D3162702D626F732D6D61)
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: State is Open
> Sep 19 13:55:18.206 EDT: Se5/5:0 PPP: Phase is VIRTUALIZED [0 sess, 1 load]
> Sep 19 13:55:18.206 EDT: Se5/5:0 PPP: Phase is TERMINATING [0 sess, 1 load]
> Sep 19 13:55:18.206 EDT: Se5/5:0 LCP: O TERMREQ [Open] id 35 len 4
> Sep 19 13:55:18.210 EDT: Se5/5:0 LCP: I TERMACK [TERMsent] id 35 len 4
> Sep 19 13:55:18.210 EDT: Se5/5:0 LCP: State is Closed
> Sep 19 13:55:18.210 EDT: Se5/5:0 PPP: Phase is DOWN [0 sess, 1 load]
> Sep 19 13:55:18.210 EDT: Se5/5:0 PPP: Phase is ESTABLISHING, Passive Open [0
> sess, 1 load]
> Sep 19 13:55:18.210 EDT: Se5/5:0 LCP: State is Listen
> Sep 19 13:55:20.210 EDT: Se5/5:0 LCP: TIMEout: State Listen
>
>
> If I'm reading this correctly, we get CONFACK from both sides, but then the
> hub side (our side) sends out a TERMREQ and LCP is then closed.
>
> We have one of the 4 T1's that appears up, but PPP won't negotiate (see
> above). I keep receiving errors on the serial interface (not the
> controller) which are all but runts:
>
> Serial5/5:0 is up, line protocol is down
> Hardware is Multichannel T1
> Description: 0004
> MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
> reliability 220/255, txload 1/255, rxload 1/255
> Encapsulation PPP, crc 16, Data non-inverted
> Keepalive set (10 sec)
> LCP Listen, multilink Closed
> Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, OSICP, IPV6CP
> Last input 00:00:00, output 00:00:00, output hang never
> Last clearing of "show interface" counters 19:04:30
> 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
> 56356 packets input, 1287207 bytes, 0 no buffer
> Received 0 broadcasts (0 IP multicast)
> 16162 runts, 4 giants, 0 throttles
> 16184 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
> 65384 packets output, 1624143 bytes, 0 underruns
> 0 output errors, 0 collisions, 0 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 6 carrier transitions
> no alarm present
> Timeslot(s) Used:1-24, subrate: 64Kb/s, transmit delay is 0 flags
>
> Can anyone else provide some ideas?
>
> Chris
>
> 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
>>
>>
>
>
>
>
More information about the cisco-nsp
mailing list