Operational issue: Packet loss at Pacbell NAP

Ellis, Stephen C (PTSS-scellis) SCELLIS at msg.pacbell.com
Wed Apr 1 00:49:02 UTC 1998


Hi Dave and Kent,

> > 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.
> 
> 
We've identified the facts that occured in this particular situation.
The problem was definitely **not** due to link congestion as we have
stats on the utilization of the OC3s.  The rerouting which occured as a
result of this problem has been corrected.  

We continue to monitor our OC3 links for any further problems.  If you
identify any additional issues, please feel free to submit a trouble
ticket with our Network Data Center at 1-800-870-9007.

Thanks,

Steve Ellis
Pacific Bell/SBC
NAP Product Manager
(925) 823-2722	(Phone)  



More information about the NANOG mailing list