Operational issue: Packet loss at Pacbell NAP

[In the message entitled "Re: Operational issue: Packet loss at Pacbell NAP" on Mar 31, 14:53, "Kent W. England" writes:]

I wouldn't jump to conclusions. Not likely that the ATM switches are
backplane loaded like the MAEs. These are Stratacom BPXs that replaced the
Newbridge 36150s over three years ago.


High bandwidth-delay product paths on a heavily loaded OC-3 to OC-3 virtual
circuit will strain the ATM switch buffers. If you can detect regularly
recurring losses on a high BDP path across an all-OC3 virtual circuit, then
look for buffer exhaustion on the OC3 interfaces. If no one at Pac Bell
knows what to do, tell them to look in the files in Fred Chang's Network
Engineering Group for Kent England's ATM NAP switch test plan and go out and
get some test gear that will stress an OC3 link in the lab. Mike Rudik in
the lab knows what to do to test for this. But my recollection was that the
BPX had enough buffers to run UBR over a full OC3.

Nope. The problem is link congestion between SJC and SFO. Pacbell
was apparently not monitoring this. By rerouting some traffic, they
were able to shift the peers that it affected. It, with 100% certainty,
is within the cloud that makes up the PB NAP.

If the loss is on DS3-OC3 virtual circuits then perhaps you are pushing more
than 45 Mbps toward the DS3. There might be a Kentrox ADSU or two left on
the NAP that could have trouble with the cisco OC3 interface at much less
than 45 Mbps.

Again, these are OC3 to OC3 in all cases.