T1 provider issue-whose fault is it....?

[dialerstring]

I'll make this short - ISP is providing us with MPLS and the CE to PE routers are using P2P at various speeds. The LEC is clean, the ISP can remote loop my router -after finding loops in their network-, but my end shows down/down their end shows up/down. The router works great in the old ckt(we are migrating to new ISP)but not the new isp ckt. I've went so far as changing out the T1Wic and I still show down/down. Keep in mind I've done over 70 turn ups with the guy and I know his configs are solid and I've checked mine also. Look at the reliability of his interface, it should be 255/255 at one point is was 147/255 and when we tried the turn up it was 188/255 and fluctuating.

Below is a show int from the ISP PE
Serial4/0.12/2:13 is up, line protocol is down
Hardware is Channelized Sonet/SDH to T1/E1
Internet address is X.113.239.X/30
MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec, rely 247/255, load 1/255
Encapsulation PPP, crc 16, loopback not set


Below is my configs-
interface Serial0/0/0
bandwidth 256
ip address X.113.239.X 255.255.255.252
ip accounting output-packets
encapsulation ppp
service-module t1 timeslots 1-4
service-module t1 fdl both
end

sh serv
Interface Serial0/0/0
Module type is T1/fractional
Hardware revision is 1.2, Software revision is 20070718,
Image checksum is 0x4144A7, Protocol revision is 0.1
Transmitter is sending remote alarm.
Receiver has loss of frame,
Framing is ESF, Line Code is B8ZS, Current clock source is line,
Fraction has 4 timeslots (64 Kbits/sec each), Net bandwidth is 256 Kbits/sec.
Last user loopback performed:
line loopback
duration 00:00:30
Last module self-test (done 1d06h): Passed
Last clearing of alarm counters 1d06h
loss of signal : 0,
loss of frame : 1, current duration 1d06h
AIS alarm : 0,
Remote alarm : 0,
Module access errors : 0,
Total Data (last 96 15 minute intervals):
3063065 Line Code Violations, 98208 Path Code Violations
2 Slip Secs, 52 Fr Loss Secs, 86355 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 2147418112 Severely Err Secs, 86400 Unavail Secs
Data in current interval (345 seconds elapsed):
7847 Line Code Violations, 1023 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 345 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 345 Unavail Sec


sho int s0/0/0
Serial0/0/0 is down, line protocol is down
Hardware is GT96K with integrated T1 CSU/DSU
Description:
Internet address is X.113.239.X/30
MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Closed, loopback not set
Keepalive set (10 sec)
Last input 1d06h, output 1d06h, output hang never
Last clearing of "show interface" counters 1d08h
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 192 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
27 packets input, 1914 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 7 giants, 0 throttles
1488 input errors, 1488 CRC, 593 frame, 343 overrun, 0 ignored, 1135 abort
51 packets output, 714 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
6 carrier transitions
DCD=down DSR=up DTR=up RTS=up CTS=down


CCNA
Network Admin

 

[burtsbees]

1488 input errors, 1488 CRC, 593 frame, 343 overrun, 0 ignored, 1135 abort

Input errors would suggest their side. Do they have 256KB BW set on their end?

Just because the LEC is clean (though is usually the problem) does not mean that their end is good. It looks like a mismatch in bw, or some mismatch.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[richinnameonly]

One thing that might have changed -- is the new ISP furnishing clocking? It's unlikely, but could explain the symptoms you're seeing. Your CSU/DSU, whether standalone or integrated, should accept clock from the most accurate timing source, and that's usually the carrier network. If, for any reason, that's not set on ISP end, and your router expects it, then nothing will work, period.

 

[m5runner]

Don't assume it's input errors. Clear the counters on the interface and see if it builds up again

 

[dialerstring]

I've cleared the interface counters and the new isp is providing the clock source. THis one is really weird.

CCNA
Network Admin

 

[DallasBPF]

I have seen those type of errors caused by a bad T1 card in the T1 shelf provided by the LEC.

------------------------------------
Dallas, Texas
Telecommunications Tech
CCVP, CCNA, Net+

CCNP in the works

 

[kbing]

Need to break down the testing at the customer location.

a.1) Is this a T1? If so, make a T1 loopback plug and put in DSU - does the interface go UP/UP? It should if the hardware isn't having any problems.

a.2) Test the extended dmarc from the smart jack to the CSU to ensure pin-outs are correct and solidly terminated.

b) test from the lec to the dmark. Is there a smart jack at the dmark? Does it test out ok? Is the smart jack got a red, yellow or green light on it?

c) if above is ok carrier need to loop to the smart jack and perform intrusive testing for at least an hour. If OK do the same to the router's DSU.

d) if all above tests out OK find out how many different carries are involved with this line. If more than 1 then have them get EVERYONE on a conference call. You'll need someone from the LEC to be onsite where the customer's router is located and all vendors techheads on the conference call so everyone can go into the configurations and verify information. Then they can test to each other and verify things are right.


I've done hundreds of turn-ups and 50% of the time we have to have a tech from each carrier plus a LEC tech onsite all talking and verifying with each other. That's last resort but 99% of the time this works. While everyone's testing and verifying there WILL be 1 guy that says's "hold on"....then a minute later everything will be working.