 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
10 messages in net.nether.puck.cisco-nsp[c-nsp] how to validate cell rates?| From | Sent On | Attachments |
|---|---|---|
| Gert Doering | Jan 20, 2005 5:46 am | |
| Hudson Delbert J Contr 61 CS/SCBN | Jan 20, 2005 10:58 am | |
| MADMAN | Jan 20, 2005 11:29 am | |
| Gert Doering | Jan 20, 2005 11:37 am | |
| Clinton Work | Jan 20, 2005 11:49 am | |
| MADMAN | Jan 20, 2005 12:33 pm | |
| Gert Doering | Jan 20, 2005 12:50 pm | |
| Gert Doering | Jan 20, 2005 1:01 pm | |
| Clinton Work | Jan 20, 2005 1:44 pm | |
| MADMAN | Jan 20, 2005 2:48 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [c-nsp] how to validate cell rates? | Actions... |
|---|---|---|
| From: | MADMAN (davi...@qwest.com) | |
| Date: | Jan 20, 2005 11:29:33 am | |
| List: | net.nether.puck.cisco-nsp | |
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"