George, Yes, you should be using egress shaping on such a link, and this is the by-the-book solution. In many cases what you would also want to do is apply a child policy with the actual QOS classes.
I have a feeling you are hitting an issue with the precision of the shaper, versus the ability of the EoSDH service to transfer all the data... In some L2 services (usually ethernet based metroE), the policy applied by the service provider uses ingress policers, and depending on the vendor/platform/configuration it may count the whole L2 byte count or in some cases only the L3 content of the frame... Another type of layer 2 service (which sounds like what you have) is EoSDH, where the SP would map NxSTM1 to a GigE port... You need to remember that STM1 in SDH is not really a 155Mbps link... This number includes overheads, and in reality would pass ~149Mbps, and this most likely is not the real number either, as it would include all the other ethernet service-related overheads (such as preamble, inter-packet gaps, CRC etc), so the real rate would be even lower. Shapers usually (at least by default, on most platforms) use the L3 byte count... This can cause a difference in the way you count the traffic rate, and the best practice I usually recommend in such cases would be to start reducing the shaper rate and find a rate at which the drops stop... I would suggest you play with the shaper , tuning it down to something like 250Mbps, see if you still have drops, and then start increasing it... Note that the L2/L3 difference is also impacted with your traffic profile (packets per second, packet length), as the overhead would be larger if your average packet size is smaller. This means that you most likely want to tune the shaper slightly lower than the highest non-drop rate to accommodate for unexpected traffic pattern changes... Arie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of George Manousakis Sent: Sunday, September 04, 2011 13:58 To: [email protected] Subject: [c-nsp] Traffic shaping on a GE interface I am facing a problem in a network and I would like some suggestions in order to solve it (and to understand it as well)!! The case is that I use GE interfaces on cisco devices as wan links but on the other side there are elements providing EoSDH services. Those elements do not operate as Ethernet routers and switches regarding (at least) the way that they buffer packets, resulting drops. For example, I have a wan link of 300Mpbs and at both ends the interfaces are Optical GE on cisco routers (7200 or ASR). Because of the multiplexing done on the wan link provider the CIR on the GE port is only 300mbps, so whenever cisco is bursting traffic (which seems perfectly normal since the clock rate on the interface dictates 1Gbps rate), the other side is dropping packets. I tried using traffic shaping (300mbps with default values for buckets Be and Bc) on the outside flow on both cisco interfaces but the result is the same. Maybe the dropping rate is reduced, but there are still packet drops. These drops are appearing only on the provider equipment, on both ports. How can I configure the MCQ in order to suppress the transmission rate on the wan capability??? I want to transmit no more that 300mbps under any condition! Using traffic shaping should solve that problem but because of the unpredictable characteristics of the traffic on the wan bursts may occur that are above 300Mbps. I have to comment that that the average traffic on the interface is less than 200mbps. The problem is caused (I assume) by the bursts in the fragments of a second that GE can support but EoSDH cannot allow. Thanks in advance. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
