03-16-2009 09:30 AM - edited 03-04-2019 03:57 AM
All,
We added a second vwic2 card to a 2800 series routerlast week, and noticed this morning that the S0/0:0 port is down on an existing multilink connection was down. We don't know if the addition had anything to do with it, but I'm not seeing where the problem lies.
I don't see errors on the serial interfaces either.
Multilink1, bundle name is IT
Endpoint discriminator is IT
Bundle up for 2d17h, 91/255 load
Receive buffer limit 12000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x0 received sequence, 0x0 sent sequence
Member links: 1 active, 1 inactive (max not set, min not set)
Se0/0/1:0, since 01:10:06
Se0/0/0:0 (inactive)
No inactive multilink interfaces
interface Multilink1
ip address 172.x.x.x 255.255.255.0
ppp multilink
ppp multilink group 1
!
interface Serial0/0/0:0
bandwidth 1544
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
interface Serial0/0/1:0
bandwidth 1544
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
show controlller T1
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20040802, FPGA: 13, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (523 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 24 hours)
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
show int s0/0/0:0
Serial0/0/0:0 is up, line protocol is down
Hardware is GT96K Serial
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Listen, multilink Closed, loopback not set
Keepalive set (10 sec)
Last input 00:00:22, output 00:00:22, output hang never
Last clearing of "show interface" counters 2d17h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
47276 packets input, 1087348 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
94628 packets output, 2934076 bytes, 0 underruns
0 output errors, 0 collisions, 4740 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags
We've open and closed the serial interface, but it didn't help.
Thanks,
John
03-16-2009 09:30 AM
The other end "show controller T1" output:
T1 0/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20040802, FPGA: 13, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (607 seconds elapsed):
0 Line Code Violations, 278 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 10 Degraded Mins
160 Errored Secs, 94 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 42867 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 1440 Degraded Mins,
27072 Errored Secs, 10380 Bursty Err Secs, 2 Severely Err Secs, 0 Unavail Secs
03-16-2009 09:47 AM
John
A little while back I had an issue that was somewhat similar (especially in what seems to be a uni-directional problem - one end looks clean and the other end is taking errors, and the interface reports protocol down). In our case it turned out to be a problem in the provider network. It was a bit ambiguous whether it was really inside their network or whether it was at the smart jack.
I would suggest asking the provider to check the circuit.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide