[c-nsp] Traffic shaping on a GE interface

[Arie Vayner (avayner)]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of George
Manousakis
Sent: Sunday, September 04, 2011 13:58
To: cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/