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