Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

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

Status
Not open for further replies.

LRS46

Technical User
Aug 4, 2005
43
0
0
US
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
 
Another trick that we use often is to put a hard loopback plug in the NIU. The carrier often tests to the front end of the NIU, but a loopback plug allows them to test to the back end. We've seen many cases where the front side was good while the back side was bad, but the telco pointed the finger at us because they could test to the NIU.

That's just a thought. It could be that the back side of the NIU is beginning to fail.
 
I had the telco "cisco" guy check the configurations on both ends. I showed him that i could connect the equipment back to back with a T1 crossover and everything was fine. He is now convinced it's a telco issue.

Jneilburger and Joamon, it looks like we have all come to the same conclusion. I even think they can isolate it to the remote T1 card. We'll see what the next phase brings, but I am fully convinced we have eliminated my equipment and cables.

Thanks for all your support. I will report back what we find tomorrow.

Larry S.
Systems & Network Consultant
 
I've had such fun dealing with SBC on T1 issues over the years. I can almost script the call progress for them.

"No problem on our end."

"The circuit tests clean."

"Must be your hardware."

"Must be your config."

"We'll have to charge you for troubleshooting."

The last call is always the same:

"Wait a second, this isn't right... <long silence> okay, we'll have a truck out in the next 4 hours."
 
PROBLEM SOLVED!

Well,

Your conversation is pretty much on target. I didn't have the router even connected and they said they they were seeing errors coming from the "customer's equipment."

Once I told them there was nothing connected, they sent out another tech (fifth one) who simply moved the line to the spare (the others said they couldn't do that) and Viola! Everything magically began to work. I plugged the router in and things are humming. They have now discovered that they had a line doubler that had been going out in one of the manholes. They replaced it and moved the circuit back over to the primary circuit. So far, several hours and no errors.

Thanks for your support!

Larry S.
Systems & Network Consultant
 
You have one last task.......
Now you need to find out where to send the diagnostic bill to SBC for troubleshooting their problem......
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top