Re: Operational issue: Packet loss at Pacbell NAP

[dlr () bungi com (Dave Rand)]

[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.

Correct.

> 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.


-- 
Dave Rand
dlr () bungi com
http://www.bungi.com