Solved

Line protocol will not stay "up" on P2P T1 circuit

Posted on 2012-03-19
8
841 Views
Last Modified: 2012-03-20
I have two point to point T1 circuits to remote location.  One of the T1s has been in service for nearly seven years, and the second is new because there was a need for more bandwidth.  It's setup like this:

Ckt#1
2811 S0/2/0 (WIC-2T) --> DTE Cable --> ADC D-Serv CSU --> AT&T --> WIC-DSU-T1 -->1841 S0/0/0 (WIC-1DSU-T1)

Ckt#2 (problem circuit)
2811 S0/2/1 (WIC-2T) --> DTE Cable --> ADC D-Serv CSU --> AT&T --> WIC-DSU-T1 -->1841 S0/1/0 (WIC-1DSU-T1)

On rebooting the CSU, unplugging and re-plugging the circuit, or issuing a shut/no shut command via CLI from the headquarters end, the line protocol comes up and then goes down about five or ten seconds later.

Circuit seems to be fine when its up briefly.  The routing tables update , and if I type quickly enough, I can squeeze a ping command to the far-side interface and get a packet or two back.  I ran a clear counters command before generating the show interface commands below, then brought the interface down and up via CLI.

It really sounds like a clocking issue, but I thought the network (AT&T) provided this (?).  The carrier swears the two circuits are setup identically which is clear channel ANSI w/ ESF formatting and B8ZS line coding.  We have four other P2P T1 circuits and this is the only one experiencing the trouble.

I did try replacing the ADC D-Serv and all the cabling at the headquarters end.  It's possible there is a bad cable or something at the far end I suppose.  No errors though on that interface.

Here's what the failure looks like:

*Mar 19 19:42:40.264: %LINK-3-UPDOWN: Interface Serial0/2/1, changed state to down
*Mar 19 19:43:36.827: %LINK-3-UPDOWN: Interface Serial0/2/1, changed state to up
*Mar 19 19:43:37.827: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/1, changed state to up
*Mar 19 19:44:03.067: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/1, changed state to down


Here is the config:

Headquarters:

DET-RTR4# sh run
interface Serial0/2/0
 description T1 to SBY (Circuit #1)
 bandwidth 1544
 ip address 172.20.150.2 255.255.255.0
 ip load-sharing per-packet
 service-policy output POL
!
interface Serial0/2/1
 description T1 to SBY (Circuit #2)
 bandwidth 1544
 ip address 172.20.0.94 255.255.255.248
 ip load-sharing per-packet
 service-policy output POL

DET-RTR4# sh int s0/2/1
Serial0/2/1 is up, line protocol is down
  Hardware is GT96K Serial
  Description: T1 to SBY (Circuit #2)
  Internet address is 172.20.0.94/29
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 01:09:58, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:01:01
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  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 772 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 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
     22 packets output, 2116 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


Branch office:

SBY-RTR1# sh run
interface Serial0/0/0
 description T1 to DET (Circuit #1)
 bandwidth 1544
 ip address 172.20.150.1 255.255.255.0
 ip load-sharing per-packet
 ip nbar protocol-discovery
 ip virtual-reassembly
 service-module t1 timeslots 1-24
 service-policy output POL
!
interface Serial0/1/0
 description T1 to DET (Circuit #2)
 bandwidth 1544
 ip address 172.20.0.93 255.255.255.248
 ip load-sharing per-packet
 ip nbar protocol-discovery
 ip virtual-reassembly
 service-module t1 timeslots 1-24
 service-policy output POL

SBY-RTR1#sh int s0/1/0
Serial0/1/0 is up, line protocol is down
  Hardware is GT96K with integrated T1 CSU/DSU
  Description: T1 to DET (Circuit #2)
  Internet address is 172.20.0.93/29
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input never, output 00:00:04, output hang never
  Last clearing of "show interface" counters 00:01:02
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/3/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 772 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 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
     8 packets output, 319 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
0
Comment
Question by:David Blair
  • 4
  • 3
8 Comments
 
LVL 17

Expert Comment

by:Garry-G
Comment Utility
Judging from the "0 packets received" on both sides, there may be a problem with either the csu/dsu units, or the actual line ... 10 seconds uptime before line protocol down is caused by the missing keepalive packets ... both sides expect the keepalives to arrive, but none seem to, so the routers take down the interfaces.
To do some diagnosis, try to get a loop first on the dsu/csu towards the local interface. The router should recognize it being looped. Then, set up a loop towards the WAN ... also, you could ask the provider to set up a loop on their equipment, which the router ought to recognize ...
0
 
LVL 17

Expert Comment

by:TimotiSt
Comment Utility
Just a guess: maybe the WIC-2T only supports one clock source, and it tries to run port 1 with the clock signal of port 0? Cisco sometimes has weird limitations...
Can you try running the second line on another WIC card in the 2811?

Tamas
0
 
LVL 17

Expert Comment

by:Garry-G
Comment Utility
If the clock source were the problem, there ought to be some increase on the "broken" packet counter, like crc or something ... also, I know we used the 2T serial cards before, with dual links (albeit to different remote sites), they also worked fine without a problem ...
0
 
LVL 1

Author Comment

by:David Blair
Comment Utility
I put a loopback plug on the CSU/DSU at the headquarters end, and the router kept the interface up.  This morning I put a loop on the WIC-1DSU-T1 at the branch side and the router didn't see it right away.  I did a shut/no shut on S0/1/0 and the line protocol came up and then went down a few seconds later.  WOW!  So, do you guys think it could be a defective WIC card?  It wasn't a brand new card.  I do have another available and can swap this evening if you think that's a good course of action.
0
Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

 
LVL 17

Accepted Solution

by:
Garry-G earned 450 total points
Comment Utility
WIC or cable ... if possible, just plug in the additional card (don't forget to turn the router off first, not hot-pluggable) and check if that works ... if not, it could be the cable ...
0
 
LVL 1

Author Comment

by:David Blair
Comment Utility
Well, I did the loopback right at the WIC interface using just an RJ-45 and a couple inches of twisted pair.  I'll replace the card this evening.
0
 
LVL 1

Author Comment

by:David Blair
Comment Utility
It was the WIC card!  Wow.  Never suspected it would be the WIC.  Thanks for pushing me in that direction!
0
 
LVL 17

Expert Comment

by:Garry-G
Comment Utility
Well, even Cisco hardware may fail sometimes, though it is pretty reliable mostly ...
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

Problem Description:   Couple of months ago we upgraded the ADSL line at our branch office from Home to Business line. The purpose of transforming the service to have static public IP’s. We were in need for public IP’s to publish our web resour…
Shadow IT is coming out of the shadows as more businesses are choosing cloud-based applications. It is now a multi-cloud world for most organizations. Simultaneously, most businesses have yet to consolidate with one cloud provider or define an offic…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now