I can't speak for every telco but I don't think we do anything unusual when it comes to T1 point-to-point circuits, deliver 1's and 0's not clock. What you did is not only the solution it is the correct way to provision a p-t-p circuit.
Dave Daniel Cotts wrote: > > I recently had a similar issue with no clock provided one end due > (supposedly to some piece of telco gear). In any case we didn't know that > was happening. We assumed clocking was from the line. It would fail > intermittantly every few days during idle traffic times. The solution was to > provide internal clocking on the unclocked end. > Let's call the unclocked end "A" and the end receiving clocking "B". Until > we found the trouble the quick fix was to loop B back on itself for a minute > then pull the loop down. It would always resync. With an internal CSU you > can view the line with show controllers t1 int number. It logs error counts > in 15 min intervals. A show controllers t1 will give 24hr totals. The error > message at B would be something like Loss of Frame received sending alarm. > Are you saying that the remote end can put a loop back towards you and you > can then do extended pings to your own ip address? > > Config should look like the following: > controller T1 0/1 > framing esf > linecode b8zs > channel-group 0 timeslots 1-24 speed 64 > (I learned about not including the speed parameter the hard way.) > ! > interface Serial0/1:0 > ip address 10.xxx.1.3 255.255.255.0 > > -----Original Message----- > > From: Stephen Hoover [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 03, 2001 9:47 AM > > To: [EMAIL PROTECTED] > > Subject: T1 install; line protocol going down and up every 30 seconds > > [7:21848] > > > > > > I am working on point to point T1 install at a small office. The line > > protocol keeps going up and down every 30 seconds and I > > cannot ping myself. > > My keepalive timers are not incrementing. The telco provider > > says that they > > are not providing the clock on this line and that we need to do so > > ourselves. My condition remains the same whether I set my > > clock to line or > > internal. The router on the remote end however seems to be > > ready to go when > > they set their clock source to line. When they set to > > internal, the telco > > provider sees framing errors on the line. > > > > Does it seem feasible that there is a clock source somewhere > > back towards > > there end of the line that their router can receive and mine > > cannot? I am > > working with the IT staff on the remote end of the link, but > > none of us seem > > to have any idea where else to go with this problem. > > > > My system works fine when I put my DSU in local loopback and > > it works when I > > put their DSU in remote loopback - so I *think* the hardware is sound. > > > > Any help is appreciated! > > > > Thanks, > > Stephen Hoover -- David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=21902&t=21902 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
