Link to home
Start Free TrialLog in
Avatar of timreeves
timreeves

asked on

Leased T1, Point to Point, serial0 up, line protocol down

I have two Cisco 2509's attached to a AT&T T1 using Paradyne 3610 CSU/DSUs at both ends.  My routers are conncted to the CSU/DSUs via DB-60 to V.35 DTE cables.  The serial 0 interface will come up and then within a minute the protocol will go down.

I tied the local loop back at the CSU/DSU and the serial 0 line when down when running the test.  I set debug on for the serial port and it looks like it getting not reply and the serial line shows down during the debug.

I had AT&T check the line between their two CSU/DSU units and they say there is no problem.  I had configured my routers and tested them before sending them using my own CSU/DSU's.  I have noticed that I have no DTR light on the AT&T CSu/DSU unit.  The other T1's I have working show a DTR light on the CSU.  I also noticed that clocking on my CSU/DSU is set for external.  Where is the clocking suppose to come from?

Any suggestion would be appricated.  Thanks
Avatar of Steve Jennings
Steve Jennings

The DTR light ON indicates that your CSU is connected to the router. So it sounds like the CSU and the router are not communicating.

Clocking terminology differs from mfgr to mfgr but generally in Master/Slave timing or Loop timing, or network timing your clock source is "external" for the CSU meaning it takes it's receive clock from the incoming pulses.

So . . . ATT says they can loop YOUR CSUs at both ends?
Avatar of timreeves

ASKER

Steve

AT&T said "we don't see any problems with the line between the CSU/DSU", I took that as they ran a loop test between the two.  

Have any solutions on getting the DTR light on.  Break-out box maybe?  I tried a different DCE  cable but serial 0 was down period.  

Guess I could connect one of the working T1's to my router with my cabling and see if the DTR light comes on?

Thanks
I've had this exact thing happen.  I wish I could remember what fixed it...  My issue was with AT&T also, but it was with a 2610.

Clocking source depends on the type and purpose of the connection - point-to-point, T1 frame-type differences, fractional vs full, etc.

As SteveJ said, DTR (Data Terminal Ready) light should be on if the CSU is talking to the router, which is the DTE (Data Terminal Equipment) in this scenario.

You might want to check the pinouts of the AT&T DSU/CSU to determine if it is set up the same as the DTE (WIC) interface of the router.  It could just be a DIP switch or some such.  

You might also want to double-check the V.35 cables to make sure the pinouts of the cable are correct for the interfaces.  I had an issue with Motorola Codex DSU/CSU's not using "standard" V.35 pinouts.  If you're running a "tail circuit" you also may need a special V.35 crossover cable.
ASKER CERTIFIED SOLUTION
Avatar of Steve Jennings
Steve Jennings

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks

I think it is a cable issue, attached a sniffer and saw physical errors from both the DCE and DTE.  Is it possible that AT&T didn't configure the port on the back of the CSU/DSU correctly?  Is it correct to assume the DTR light on the CSU/DSU should be on even if problems exist at the far end?  This should be the hand shake between my local CSU/DSU and my local router, right?  

Thanks
Depends on the problems.  If there is a connection between the CSU/DSU and the router, the DTE light should be on.  If the pinouts don't match, even if the connection is otherwise good and the equipment is functioning, then, yes, the DTE light should be on.

Is this a standalone DSU/CSU device or a blade in a channel bank?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Monday morning update:

Ok, I'm using the CSU/DSU that AT&T provides at both ends. They wired the T1 jacks and tested the circuits.  We had AT&T install this line about two months ago and we're just now getting around to using it.  I have a V.35 DTE cable attached to tje short 25 pin- to female V.35 cable that comes from port 1 on the CSU/DSU. The Cisco router has serial 0 configured to use HDLC.  I had both routers talking together in a test lab so I think things are ok on the encapsulation.
I will call AT&T to check where the clock is coming from, I suppose their using the network clock.

thanks for the help, hope to find the answer early this week.
When you had both routers talking together in the test lab, did you have them configured as "back-to-back" . . . because if you did, one of them had to have an interface configured as DCE . . . meaning one of them had a "clock" command. This wouldn't keep the DTR light from coming on, but it would keep the link from coming up.

Steve
The routers were connected via csu/dsu with a T1 simulator between the CSU's.  I found a bent ping on the 25 pin connector, pin 20, fixed it but still no connection between the CSU and my router on the local end.
Can you quickly . . . or during off hours . . .swap the cable with a known working cable?

Steve
I had a similar problem with same technologies but E1 and not T1 :)

Try to invert your tx-clock on one of the routers. That's inside the interface configuration mode "invert tx-clock" (if your routers are Cisco).

When cable lenght between your CSU/DSU and the router is in a range of feets may occur this problem wich causes miss the clock afeter few seconds because the time of propagation. Yes, it sounds science fiction but it's true.

Good luck!

Juanma Merino
Barcelona
I got it working .  The problem was with the configuration on the CSU/DSU at our end.  The port 1 on the 3160 has some problems assigning channel and keeping configure.  We configured port 2 for the full T1 and V.35 and everything worked.  Took about 30 minutes to get it right.

Thanks, for the help.  Lesson learned:  just because the network is up doesn't mean a thing if your local port is not configured right.

The second man from AT&T was of great help in finding and fixing the problem.  Thanks.