I have 3 private line T1s going into two VWIC-2MFT-T1 cards that are all on the same NM. These VWICs give me four T1 ports of which I am using the last three. The problem I'm having is that I get a tremendous amount of line code violations, slips and other errors on my Cisco 3662 (in corporate office). On the other ends of these T1s, I don't get the errors. These remote ends are set with internal clocking while the 3662 ends are set to line. I have called AT&T and of course they test the line fine and show it to be set up for ESF and B8ZS. I don't know what the problem is. The demarc is extended about 300 ft but playing with the cable length didn't make any difference. Any help would help. Here is a sample:
T1 3/1 is up.
Applique type is Channelized T1
Cablelength is short 133
Description: T1 to Las Vegas
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20000922, FPGA: 15
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
Current port master clock: recovered from controller 3/1
Data in current interval (11 seconds elapsed):
163 Line Code Violations, 445 Path Code Violations
11 Slip Secs, 0 Fr Loss Secs, 11 Line Err Secs, 1 Degraded Mins
Have you checked with the carrier to make sure they are not providing clock ?
Work with the carrier have them provide loops toward you from different test points you should see the line go up up (looped) then ping yourself. If you drop pings there is a problem with the carrier. If no drops no carrier problem .
Carriers will usually test from the closest test point to your site and will not test in the other direction .
You may need to play with the clock source. If you are using a service module, you may need to add the command ' service-module T1 fdl both ' THis allows the carrier to loop your csu.
If all three lines are form the same carrier, try changing the clock source from 3/1 to one of the other ports.
You may want to try catching clock from each of the three lines (3/1 gets clock from 3/1, 3/2 gets clock from 3/2...)
What kind of cable is that 300ft run?
If it'sUTP (Cat3,4,5,5e,6) you may want to bump the cablelength up a notch(the cable may appear longer than it is). UTP is (last time I looked) not the "correct" cable type for T1 transmission, though it is (by now, probably) the most often used. I believe the spec calls for "Premises" cable - two twisted pairs, each pair shielded, in a jacket with an overall shield.
All of the T1s are AT&T lines and I've tried a couple of things with them. I've tried setting the clock to line/line, internal/line and line/internal. Having the clock set to internal on the 3662 bring the T1 down but setting line/line or line with the remote location to internal gets the line up with errors. This is a factory so the telco terminates there stuff at the back of the factory. Our phone vendor then pulled 100 pairs from this area to our computer/telephone room. We also have a PRI going into a PBX in the phone room that has no errors that is using some of these pairs. I did play with the cable lengths but it didn't seem to make a difference.
I would be looking at the cable extended from the DMARK. As the previous responder indicated, shielded twisted pair is the best choice. Since you don't have that at this time, try this. Separate the TX pairs from the RX pairs. For example, put the TXs on pairs 23,24 and 25 and the RXs on 48,49 and 50.
Also, do you know the signal level at the demark or at the computer room? A signal level of -15db to -20db should be good. If you don't know the level and have no way of measuring it, I would set the cable length to 'long'. ATT is probably handing the signal to you within the range that I indicated above. You are adding loss to it. If the signal loss is too great, the peak to peak voltage is below the level necessary to indicate a binary 1.
If you have all of your T1's coming in on the same 100 pair cable, you might want to try and move them to different bundles. I have seen problems where multiple T1's in the same bundle of cable can cause problems. Try spreading out the T1's to three seperate bundles.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...