Two P2P T1s on 3825; one works - one doesn't identical configs 3

[LRS46]

I have a Cisco 3825 with two WIC-1DSU-T1-V2 cards at the main site.

At the first remote site, we had a 1721 with a WIC-1DSU-T1-V2 card.
At the second remote site, we had a 2811 with a WIC-1DSU-T1-V2 card.

We are doing some simple bridging for the time being, and have come up with very perplexing issue. We cannot get a connection established at the first remote site. It was originally working for three days then went down.

The two WIC cards in the 3825 are configured identically and the LEC (SBC) has been out and done a head to head test of the lines and says everything is the same on both lines. The 1721 and 2811 WICs are also configured the same.

When we plug in our equipment they say they see errors on the link to the first remote site. So, we swap the links, remote1 to int s0/2/0 and remote2 to int s0/1/0. The link to remote1 is still down. The link to remote2 is still fine.

We then swap the remote routers, the 1721 goes to remote2 and the 2811 goes to remote1. Still remote1 is down.

We then put new WIC-1DSU-T1-V2 cards in the 3825 and 2811 (which is now at remote1 site) and configure everything from scratch. site2 comes up no problem and site1 is still down.

Next, per the carrier tech, we add clocking to the 3825 interface like this:

clock rate 64000

service-module t1 clock source internal
service-module t1 framing esf
service-module t1 lbo none
service-module t1 linecode b8zs
no service-module t1 remote-alarm-enable

and to the remote interface on the 2811 like this

service-module t1 clock source line
service-module t1 framing esf
service-module t1 lbo none
service-module t1 linecode b8zs
no service-module t1 remote-alarm-enable


No luck. The test the lines again and say they can get across without a problem.

We then clear all configurations and start over from scratch. Nothing changes.
Next, I get two Cisco 1605's, configure them from the basic configuration menu and connect them on each end. No luck. SBC insists it is our equipment.

Here is the last configuration of the 3825. I can't get the other ones right now, but they are basic configs.

Current configuration : 1192 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname depaul
!
boot-start-marker
boot-end-marker
!
enable secret @@@@@@@@@@@@@@@@
enable password ##########
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip routing
no ip cef
!
no ip dhcp use vrf connected
!
!
no ftp-server write-enable
!
!
bridge irb
!
!
interface GigabitEthernet0/0
no ip address
no ip route-cache
duplex auto
speed auto
media-type rj45
negotiation auto
no mop enabled
bridge-group 1
!
interface GigabitEthernet0/1
no ip address
no ip route-cache
duplex auto
speed auto
media-type rj45
negotiation auto
no mop enabled
bridge-group 1
!
interface Serial0/1/0
no ip address
no ip route-cache
mop enabled
bridge-group 1
!
interface Serial0/2/0
no ip address
no ip route-cache
mop enabled
bridge-group 1
!
ip classless
!
no ip http server
!
dialer-list 1 protocol ip permit
!
control-plane
!
bridge 1 protocol ieee
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password #############
login
!
scheduler allocate 20000 1000
!
end

Serial0/1/0 is down, line protocol is down
Hardware is GT96K with integrated T1 CSU/DSU
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 252/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:41:45, output 00:41:45, output hang never
Last clearing of "show interface" counters never
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/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
6734 packets input, 952505 bytes, 0 no buffer
Received 780 broadcasts, 0 runts, 10 giants, 0 throttles
67012 input errors, 67012 CRC, 29209 frame, 16617 overrun, 0 ignored, 48942 abort
10466 packets output, 1755737 bytes, 0 underruns
0 output errors, 0 collisions, 5613 interface resets
0 output buffer failures, 0 output buffers swapped out
32 carrier transitions
DCD=down DSR=up DTR=up RTS=up CTS=down

depaul#


What else can I do? I have had three independent sets of hardware that plug and play just fine on one link and nothing but alarms on the second link.

Thanks for your time.


Larry S.
Systems & Network Consultant

 

[JOAMON]

67012 input errors, 67012 CRC, 29209 frame, 16617 overrun, 0 ignored, 48942 abort
10466 packets output, 1755737 bytes, 0 underruns
0 output errors, 0 collisions, 5613 interface resets

looks to me like a telco problem........tehay always like to blame your equipment....would be interesting to see the output from the other side as well.

 

[JOAMON]

Also...look at the following on your interface:
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,

Note the speed it is detecting......B8ZS should be 1544....ANSI(robbed bit) will read as 1536...ask the tek about that.

Should read as follows:
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

 

[LRS46]

Joamon,

Interesting that you pointed out the 1544 versus 1536. That's what I thought was odd, because we've always been told a T-1 was 1.544Mb. But, when you multiply 64k x 24, it equals 1536.

So I looked at the Cisco web site and the 1536 was referenced for T1 with 64k channels (no mention of the linecode; this was just skimming every T1 document I could find). However, I am going to bring that back up because I recall that the BW should be 1544 and 1536, just like you said.

Thanks for the responses. I feel a star coming on!


Larry S.
Systems & Network Consultant

 

[jneiberger]

You might want to try a new WIC at the remote site. The first V2 DSU WICs on the market were buggy and had lots of problems. Many people couldn't get them to work at all.

 

[jneiberger]

You might want to try a new WIC at the remote site. The first V2 DSU WICs on the market were buggy and had lots of problems. Many people couldn't get them to work at all.

 

[LRS46]

I think I eliminated the WIC issue by swapping them with the WIC at the other location. I also used another set of routers and had the same issue.

My curiosity still lies around the bandwidth statement from Joamon. However, I can't find anything that explicitly says the bandwidth can't be 1536 with B8ZS.

Is there a way to determine what the linecode is on the T1 without involving the carrier? My reason for this is that they have insisted that both T1's are identical and I know for sure that the one that is working is configured for B8zs and have told us they are going to bill us for the troubleshooting since it's "not their" problem. However, every document that I have been able to research points to either the clocking or the framing.

I won't be at the site until Monday, but at that point, I want to be as ready as possible because that site has been down for two weeks and they are po'ed at me big time.



Larry S.
Systems & Network Consultant

 

[jneiberger]

Well, if you're concerned that they might have the span configured for AMI, configure both ends to AMI and see if you can pass any traffic. I know that it won't work very well, but it should work a little bit, at least enough to determine if they're using AMI.

I think that would be a bit unusual, though, at least in our area. Qwest uses B8ZS for everything unless we ask for AMI, and even then they usually install B8ZS.

 

[BuckWeet]

Have you tried a loopback at either end at all?? Then see if the circuit comes up.. This will eliminate hardware as the problem if the circuit still doesn't come up..

Also do a 'show service-module' command and look at the T1 parameteres..

BuckWeet

 

[LRS46]

Originally we did loopback tests, but not lately. Before, we were somewhat convinced that it was a defective WIC card. As for carrier loopback, they say all is clear.

But I take this back to my original question:

If two T-1s are conditioned identically (that's what SBC insists), then how is it possible that two routers can work on one circuit and not the other, assuming that the configuration stays the same.

There is no other equipment hooked up to the routers. This is just router to router across two different spans. Yet, the carrier has involved at least six diffent people who all come back to the router being the problem. I just don't get it, nor do I know how to prove the T-1s are different. I will try the AMI configurations this morning. I should mention one other critical piece of information: the two T-1s were not installed at the same time. One has existed for several years but was operational on a Baystack unit that has since been removed and probably dumped. The working T-1 was just installed in September.

Larry S.
Systems & Network Consultant

 

[MadanB]

Hey guys,

How's this going to work when in the config he has "no ip routing". How are any routes going to go anywhere when you explicitly tell it not to?

 

[jneiberger]

MadanB,

He is using transparent bridging at the moment, not routing.

 

[MadanB]

ahh, I see! It's funny because I had the same problem with 1 of our PtP and it ended up being that no ip routing was enabled. As soon as I removed it, everythign started to flow

 

[LRS46]

Yes, it is transparent bridging but the issue is that we are getting errors on the line. The carrier is seeing them as well as we cannot get the WIC amber alarm to go away.

This morning I hooked up two 1605's and new cables. Still no luck. I get DCD=down DSR=up DTR=up RTS=up CTS=down, amber on the alarm and green on the carrier detect.

Larry S.
Systems & Network Consultant

 

[LRS46]

HEre is the show-module serial0 off the 1605 at the main site.

Module type is T1/fractional
Hardware revision is 0.96, Software revision is 1.07,
Image checksum is 0x8510A6B6, Protocol revision is 0.1
Transmitter is sending remote alarm.
Receiver has loss of signal, loss of frame,
Framing is ESF, Line Code is B8ZS, Current clock source is internal,
Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.
Last module self-test (done at startup): Passed
Last clearing of alarm counters 00:23:09
loss of signal : 1, current duration 00:23:00
loss of frame : 1, current duration 00:23:00
AIS alarm : 0,
Remote alarm : 0,
Module access errors : 0,
Total Data (last 1 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations
1 Slip Secs, 900 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 900 Unavail Secs
Data in current interval (478 seconds elapsed):
255 Line Code Violations, 0 Path Code Violations
162 Slip Secs, 315 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins
161 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 315 Unavail Secs

Larry S.
Systems & Network Consultant

 

[LRS46]

here is the same thing 15 minutes later

lamision#sh service-module serial0
Module type is T1/fractional
Hardware revision is 0.96, Software revision is 1.07,
Image checksum is 0x8510A6B6, Protocol revision is 0.1
Transmitter is sending remote alarm.
Receiver has loss of signal, loss of frame,
Framing is ESF, Line Code is B8ZS, Current clock source is internal,
Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.
Last module self-test (done at startup): Passed
Last clearing of alarm counters 00:31:25
loss of signal : 1, current duration 00:31:16
loss of frame : 1, current duration 00:31:16
AIS alarm : 0,
Remote alarm : 0,
Module access errors : 0,
Total Data (last 2 15 minute intervals):
255 Line Code Violations, 0 Path Code Violations
585 Slip Secs, 1215 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins
583 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 1215 Unavail Secs
Data in current interval (69 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
69 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
69 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
lamision#

Larry S.
Systems & Network Consultant

 

[jneiberger]

Have you checked the cabling at the demarc on each end? Is there an extended demarc involved? I'd check and re-punch all connections just to be on the safe side.

 

[JOAMON]

After checking you cabling and as you have pretty much exhausted a hardware problem it is time to insist that your provider come onsite and perform and end to end intrusive diagnostic with their equipment.

 

[LRS46]

Yes. I even took it one step further and used a new cable in the room. The extended demarc is only about 15 feet but we have redone that cable twice. We even tested the cables for another link and they worked fine.

I have an appointment to work with the carrier technician again.

Thanks for all your input. I will get back with you soon.


Larry S.
Systems & Network Consultant

 

[JOAMON]

One last thing you might try. Pull the boards out of the suspect T1 NIU at both ends. Then replace them and try the connection once more. Basically this will reset the connection from the NIU to the CO at both ends.