[c-nsp] to shape or not to shape

[Mindaugas Kubilius]

For subrate links also for tunnel interfaces you need shaping. For
interfaces that operate at full physical speed (E1 in your scenario) you do
not need shaping and the queuing policy can be applied directly on the
interface. There should be no difference in a way how router handle buffers
with a CBWFQ policy map regardless if that is applied behind the shaper or
directly to the physical interfaces.

As it was already mentioned, router does not know the real throughput of the
subrate link, hence the shaper is used to create artificial congestion point
at 5Mbps while physical the port is running 10Mbps.

The same holds true for tunnels, even if they are targetted to operate at
the full physical speed of the underlying interface - you still need shaping
to the physical speed (imho, even maybe bit less to adopt for the tunnel
overhead)

Regards,
Mindaugas

Date: Sat, 9 Oct 2010 21:42:56 +0200
> From: Roger Wiklund <copse at xy.org>
> To: Mikael Abrahamsson <swmike at swm.pp.se>
> Cc: Cisco-nsp <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] to shape or not to shape
> Message-ID:
>        <AANLkTikO+4ZTVW3u7C8wZxwxvV=JyqDgSbhCc8_LQXR9 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > Buffers are not infinite, so you might still see tail drops.
>
> Indeed, but I'm thinking if I only apply the "qos" policy-map, I
> switch from fifo to CBWFQ with multiple software queues, and buffers.
>
> If I on top of that do shaping, would I not utilize yet another
> buffer? I.E. the shaping buffer.
>
> >From Cisco:
>
> shape max-buffers
>
> To specify the maximum number of buffers allowed on shaping queues,
> use the shape max-buffers class-map configuration command. To remove
> the maximum number of buffers, use the no form of this command.
> Defaults
>
> The default setting is 1000 buffers.
>
> It is a bit confusing, as we shape a 1984 to 1984. If we shape we uses
> the shaping buffers, it will hold the packets in the buffer until the
> next Tc. After that It can be sent, will it then utilize the interface
> buffers if it cant be sent right away?
>
> Now I'm even more confused ... :)
>