[c-nsp] OK, what is a cheap and dirty hack to test a port

Wed Oct 15 14:57:53 EDT 2008

Paul,

Thanks.
We do have one side set to internal and the other to line and did forget
about it for years.
I believe one side of our circuit is encapsulated in a DS3, since one tester
said they couldn't loop since they had to loop the whole DS3.
The other side must be just a regular T1 and they are cross connected by the
DACS at the central office.  Verizon said they have to be in sync.
Something must have happen for them to be out of sync after all these years.

Luan Nguyen
Chesapeake NetCraftsmen, LLC.
www.NetCraftsmen.net

-----Original Message-----
From: Paul G. Timmins [mailto:ptimmins at clearrate.com] 
Sent: Wednesday, October 15, 2008 12:03 PM
To: Luan Nguyen; Roy
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] OK, what is a cheap and dirty hack to test a port

Most modern sonet gear does not provide clocking to individual DS1s
running it. The only reason clocking ever existed on point to point
circuits was that the older gear couldn't avoid being an active
participant in the circuit. It's possible the carrier you're using has
upgraded the equipment, and where it was once providing the clocking
(which it couldn't avoid previously), it's now on gear that can now act
indistinguishably from a straight piece of wire (of course, it has to
follow T1 line encoding and framing, but beyond that..).

I've seen this plenty over the last 5 years as carriers upgrade, and
roll DS3s onto newer gear. One night, the clocking gets funky, and you
have to enable clock, which was causing problems before, but now works
fine.

(Of course, we don't feel it as much, because we are syncing our gear
off the BITS in our CO, so we'd be in sync with the ILEC whether we
provide clocking or not, so we just provide clocking on our end of all
loops, and slave the customer sites.)

It's also possible for two devices set to clock off line to work for a
while, without anyone providing external clock. Since there's not really
a "clock signal" per se, but just a directive that says whether your
internal source is authorative, or whether you should be sending your
own frames in sync with the frames you're getting off the line, both
devices can feed off of each other (a device without line clock will
fall back to internal clock, and start sending frames. The other device
will see the clock signal on the line, and sync with it. Then the
original device sees the framing on the line, and syncs with that. The
devices then sync off whatever each other are sending. Because this
isn't precise (but can be precise "enough"), it's possible for the line
to work for a while like that, until power blips, line hits, or random
cosmic noise cause the whole thing to fall apart).

Anyway, the network has to actively participate in the circuit to
"provide clock", and the field has been running away from this for
years. Set one side to line clock, and one to internal, and forget it.
It's a single line of config. :)

-Paul

PS: I'm using the term "providing clock" because that's what we're
calling it in this thread. The way you should actually think about it
though, is using your own clock reference, or using the reference coming
from the line. In the PSTN world, everyone "provides clock" (uses their
own clock reference) and you don't trust the line clock from anywhere.
Because your clock references are in sync with each other (because
you're syncing off a cesium reference, using GPS, or CDMA, or you have a
BITS T1 from the local LEC, or some combination of those) everything
works flawlessly (insofar as that's possible in real life). CPE aren't
expected to have their own stratum 1 reference clock, so they just trust
the line signal. If you're connecting CPE to CPE, you're going to have
to provide your own reference clock, and it doesn't have to be stratum 1
since you're not interfacing with anyone else (unless you're passing
through some real old DACS or Mux gear that actively participates in the
circuit, rather than just encapsulating it in a DS3 and sending it on
its way through the network) it doesn't have to be in sync.

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Luan Nguyen
> Sent: Wednesday, October 15, 2008 10:51 AM
> To: 'Roy'
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OK, what is a cheap and dirty hack to test a port
> 
> It's on fiber.  I asked if we could get network timing from 
> them, but they
> said no, not on this type of circuit. 
> Also, this circuit has been working for years with the same setting :)
> 
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> www.NetCraftsmen.net
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Roy
> Sent: Wednesday, October 15, 2008 10:36 AM
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OK, what is a cheap and dirty hack to test a port
> 
> Just because its a point to point circuit doesn't mean one side has to
> have internal clocking.  This is only true if the circuit is 
> copper all
> the way.   There are lots of reasons that the telco would have its own
> equipment installed on the circuit and you would need network timing.
> 
> Roy
> 
> Luan Nguyen wrote:
> > Is it a Verizon circuit?
> > We have a T1 circuit with Verizon and have the same 
> problem.  We have a
> > point to point circuit, so one side has clocking set to internal to
> provide
> > the clocking and the other side feeds from the line.
> > I wrote the problem up at http://ccie-security.blogspot.com/
> > But basically, it will be up for a some hours then down, 
> then I call them
> to
> > test and it's good again.  Sometime it's good just by 
> unplug the cable and
> > plug it back.  Like you, we changed everything and that 
> didn't help. 
> > Finally, we talked to a knowledgeable Verizon tester and he 
> mentioned the
> > rate on the line is ~17 which is high.  It should be around 
> 0 or negative.
> > He said that's because of mismatch clocking between our 
> hardware and the
> > central office crossover equipment. The normal tester won't 
> look at this,
> > they only do the loopback pattern testing, so you should 
> ask them about
> the
> > rate of your line.
> > They swapped one smart jack, but that didn't help, so they 
> will swap the
> > other today.  Hopefully that will do it.
> > Good information here about troubleshooting T1
> >
> http://www.informit.com/library/content.aspx?b=Troubleshooting
_Remote_Access
> > &seqNum=61
> >
> >
> > Luan Nguyen
> > Chesapeake NetCraftsmen, LLC.
> > www.NetCraftsmen.net
> >
> > ...
> >   
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 