@alexander.lechner wrote:
A colleague has the 9200L tested and said it was performing reliable until 200 Mbit.
For my understanding shaping is CPU/ASIC intense and more suited on routers.
Well, without much more information about how your colleague "tested", cannot really comment on the validity of such results.
As to the intensity of shaping to a CPU and/or ASIC, that's certainly a possible issue, especially if a switch's CPU has to do it.
The reason being, switch CPUs are generally sized just for control plane needs, as data plane needs are almost always provided by ASICs. Routers, though, CPUs are generally sized to support both control plane and data plane needs. I.e. a router's CPU often provides much more performance capacity than a switch's CPU, yet often it can only provide a fraction of the data plane throughput of a switch's ASIC(s). However, even the later/newer smaller routers often provide additional hardware for data plane handling.
In other words, I wouldn't agree that shaping is more suitable on a router if supported on a switch. Of course, if a switch doesn't support shaping (historically many smaller Cisco switches didn't, or they provided limited shaping support [ditto with many other router features]), likely that's due to lack of ASIC support.
@alexander.lechner wrote:
The interface is gig but the CIR is about max 980 Mbit (depends on paketsizes) + 60K burst to be exact (documentation).
The configuration i provided should ensure a stable transmission.
Again, I would seriously question shaping a gig interface at 950 or 980 Mbps. A higher bandwidth interface, sure, but shapers, in theory, tries to simulate the throughput of a physical interface.
Since mention is made of "depends on packetsizes", yes a Cisco shaper's transmission rate may be need to be set lower than the true CIR because (I believe most) Cisco shapers historically only counted L3 packets sizes, i.e. they didn't consider L1(preamble, SFD & IPG)/L2(frame) overhead. (However, some Cisco shapers now can count some such overhead too, see Ethernet Overhead Accounting.)
The percentage of L2 overhead varies very much dependent on the L3 packet's size. If the CIR is truly the equivalent of a like physical bit rate, a 1500 bytes packet, without a VLAN tag, would need 1538 wire bytes, or (if my math is correct) a rate of 975 for gig. (I.e. just a tad smaller than the suggested 980.)
The other extreme, if minimum size 64 byte frame were being sent, needing 84 bytes, providing a payload of up to 46 bytes. That's an overhead of a tad more than 45%, even more if a IPv4 packet doesn't need all 46 bytes (i.e. it's padded).
In my experience, using a packet counting shaper, I've found setting shaper's transmission rate about 15% slower than CIR rate, often works well, for "typical" variable sized packets, but your mileage might vary.
To summarize:
If your provider CIR is supposed to be like physical (some media) bandwidth, then the optimal handoff is a physical interface (like media) running at the physical bandwidth.
If the physical interface offers more than the CIR, than a shaper (or policer) can be used to not overrun the CIR. However, not all shapers (or policers) account for bandwidth the same way a physical interface uses it. If not, you often need to specify a lower transmission rate. If the unaccounted overhead is variable, unless you set for worst case, you may overrun the CIR.
Burst settings determine how closely a shaper (or policer) "tracks" a physical interface of the same bandwidth. Smaller burst settings more closely track a physical interface, but tend to increase processing overhead. (Too small burst settings can result in policers' effective transmission rate much lower than a "similar" physical interface transmission rate would be. [BTW optimizing burst settings can be "complex".]}
