Hi,
On Thu, Jan 20, 2005 at 09:50:07AM -0700, Clinton Work wrote:
Gert, I agree with your calculation, but it really depends upon how the
Telco has built the ATM VC inside their network. The Telco could have
used a VBR PVC with an unforgiving CDVT (Cell Delay Variance Tollerance)
value.
This is my suspicion, yes. They *claim* it's UBR, and UBR is what I have
configured...
Are the CDVT values specific to the configured VC types? They claim
a CDVT value of "750", though I'm not sure what to make out of it, or
how to match this to Cisco config statements.
The only soltuion may be reducing your PCR value until the packet
loss goes away.
This is what we did now - "ubr 2150" seems to make everything well-behaving,
but it means we're paying for bandwidth we can't use, and their own
documentation how we should configure things is not working, and I'm
not going to accept this so easily.
(The return path is even worse. Their own Ethernet->ATM/SDSL bridge is
not doing *any* shaping, so as soon as the customer side is sending
large amounts of traffic, the switch polices, both AAL5 and OAM cells,
and we see packet loss *and* "line protocol down" flaps. Their official
recommendation is now "connect a router that can do traffic shaping".
We've been through this with their ADSL/Ethernet product, and they
*have* fixed their CPEs, it just took half a year... *sigh*)
gert
10 messages in net.nether.puck.cisco-nsp[c-nsp] how to validate cell rates?
