[c-nsp] how to validate cell rates?

[MADMAN]

   Try shaping down a little more, roughly 10%.  I do know that earlier 
IOS did not always take into account the overhead in the ATM cell when 
shaping.  I have seen this several times in the past though admittedly 
not in 12.3.

   Dave

Hudson Delbert J Contr 61 CS/SCBN wrote:

> gert,
> 
> a valid assertion indeed except that even if one finds substantiated
> data to backup any complaint to the telco, it doesnt matter as they 
> will ALMOST NEVER admit mis-configurations at the telco end.
> 
> in other words, to what end would proving it to them resolve?
> 
> if this type of connex is a cash cow for them and they have
> a non-complaining customer base, what do you think will happen to the 
> service nothing. 
> 
> i've had my fill of euro-telco's.
> 
> ~piranha
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Gert Doering
> Sent: Thursday, January 20, 2005 2:47 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] how to validate cell rates?
> 
> 
> Hi,
> 
> we have an interesting problem here (as usual, a Telco is involved)...
> 
> Customer has an SDSL line, which is handed to us as an ATM PVC with
> ATM AAL5 SNAP encapsulation (customer side is bridged to ethernet by
> the Telco termination device).
> 
> Our side is configured to use "ubr 2303", which translates to
> 5432 cells/second ("show atm vc <name>").  Which is exactly the cell 
> rate that we are permitted to use (actually it's 5433 c/s, but you 
> can't configure that on Cisco gear - ubr 2304 translates to 5434 c/s)
> 
> Our gear is a 7206 with 12.3(9) and an PA-A3-OC3SMI.
> 
> Now the line drops packets.  Open ticket with Telco, telco claims 
> "you are sending too much data, we see up to 5600 cells/seconds, so
> our ATM switches drop cells due to policing".
> 
> We have *never* seen this with lots of ADSL lines on the same router,
> also handed off as ATM PVCs (some aal5mux ip, some aal5snap), so I'm
> not really willing to believe their claims - I'm more willing to assume
> some misconfiguration on their end.  But I can't prove that.
> 
> So my question is: is there a way to find out peak cell rate on a given
> PVC?  Or are there any known bugs in 12.3(x) with PA-A3s that could 
> result in the router exceeding the configured PCR?
> 
> Maybe it's just a question of measurement intervals (like "Cisco calculating
> PCR on a per-second basis, while Telco gear polices on a per-0.5-second
> basis")?  Do the ATM standards specify on which time base PCR has to be 
> calculated?
> 
> thanks,
> 
> gert
> 
> 

-- 
David Madland
CCIE# 2016
Sr. Network Engineer
Qwest Communications
612-664-3367

"Emotion should reflect reason not guide it"