Dave Close wrote:
>
> On January 24, I wrote:
>
> > We have been using the T1 card since it became available to expand
> > a PM3 to two local lines (PRI or CT1) while still keeping our frame-
> > relay link. A nice idea which saves a lot of money. But we have had
> > several cases where the T1 card seems to be much more senstitive to
> > the frame circuit than was line1. If we could identify which line
> > parameter is the culprit, we might be able to work with the telco
> > to fix it. Since we haven't yet, we're stuck with replacing the T1
> > cards or just adding another PM3.
> >
> > The situation is that a working frame connection, which has been
> > "CONNECTED" for hours or weeks, will suddenly revert to "CONNECTING"
> > status. A reset of W48 has no effect but a reboot of the box always
> > restores the circuit immediately, until the next time the problem
> > happens. Telco can also correct the problem by momentarily looping
> > the circuit - if you can reach them in a timely fashion. Thinking
> > back, I don't believe we've seen this when the frame circuit is
> > connected to line1.
> >
> > In one case, we went through three T1 cards via RMA and never got
> > the circuit to work. Adding a second PM3 and putting the frame back
> > on line1 fixed the problem immediately. In another case this weekend,
> > a T1 card which had been working flawlessly for several months suddenly
> > began to exhibit the problem after the bandwidth on the frame circuit
> > was increased. Note that we have other T1 cards which have not seen
> > the problem and a few which see it every few weeks.
> >
> > The experience with the bandwidth increase indicates to me that
> > the T1 card is more sensitive to something on the line than are
> > the built-in ports. Of course, when a telco increases bandwidth,
> > they allocate different facilities in their switches. So, although
> > we continued to use the same T1 card and same local loop, there were
> > clearly several telco changes. Even reducing the bandwidth to its
> > former value did not clear the problem, but is unlikely that we were
> > put back to exactly the same configuration as before.
>
> We have since learned that, in this case, the problem seems to have been related to the timing source of the telco circuit. When telco increased the bandwidth on the circuit, they moved it to a DS3 DACS and set it for network timing. Of course, we were also set for network timing - not a good situation. To fix the problem, they moved the circuit to a 1-0 DACS and set it for looped timing. In addition to the timing problem, I was also led to believe that the DS3 DACS, at least for this telco, may have timing problems, and the 1-0 DACS is more reliable. (Pardon me if I've used the wrong terms for the DACS; I'm quoting literally from oral conversation.)
>
> Despite the timing glitch, the upgraded circuit was able to work fine on line1 of the PM3. I've never been able to see the timing source on that line, it doesn't appear on "show line1", so maybe it was set differently. If it was the same as line2, then the T1 card is somehow more sensitive to timing.
>
> I have also learned that the same problem can occur on a heavily loaded circuit. Essentially, the LMI packets can be discarded just like any other packet, and the result is a loss of LMI sync.
>
> I'd still like to be able to reset the problem without re-booting. However, it is line2 which is stuck, not W48, and "reset line2" doesn't do anything. Any ideas?
> --
> Dave Close Quik Internet
> +1 949 548 2171 Costa Mesa California
> dclose@quik.com http://www.quik.com/
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
> Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>