On (2011-12-25 14:46 -0600), Anton Kapela wrote: > A rule of thumb I've kept in mind is to shape at ~80% of the overal > CIR from your isp. Then, apply queueing to taste. A fairly useful & > Same for upstream, though, you can typically get away shaping within > 95% of the configured CIR bitrate. Say you had 5 mbits/sec upstream.
As I understand this, this is due to different platforms calculating different things in shaper. If you know exactly what shaper is doing, and your congestion point is constant rate, you can configure it to 100% ES20 calculates L1 speed, ES+ and SIP400 calculate L2 speed. So consider you have topology as such ES+ -10GE- metrol2 -FE- customer There is no QoS in metrol2<>customer, but there is QoS on ES+>customer subinterface. Per default if you set ES+ shaper to 100Mbps, the shaper will think traffic rate is in-contract and will forward, while actual L1 rate exceeds FE physical rate and metrol2 is forced to drop frames out-of-contract. In this graph I'm sending traffic in above topology and around 130s mark I apply 'hw-module slot 2 account np 0 out 24' to the ES+ card. http://ytti.fi/after.png So what happens here is, before above command the metrol2 is dropping packets, ES+ is passing through shaper. After telling the ES+ card to calculate L1 speed, it notices that traffic is out of contract and it can start dropping BE traffic, keeping other classes undropped. (24B == preamble + SFD + CRC + IFG) It gets really wonky if you have to do QoS on ethernet interface for downstream ATM congestion point, some boxes are able to account for cell overhead in Ethernet interface, but that is somewhat rare selection of boxes. Often people just tinker with shaper rate to make it less than 100% to accomplish the same. But it's suboptimal solution, as overhead is not constant, in ATM very much so but even in ethernet you cannot get reliable results for all frame size spreads if your shaper is calculating wrong speed. Of course if you only ever run QoS in the last-mile interface, where actual congestion occurs, things get very very easy. QoS in aggregation takes care. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
