[nsp] GRE Tunnel QOS with Burst Capability

[Mark Richardson]

Hiya,

We have an ADSL service in Italy where the provider is offering us a CIR of
256K with a 256K burst going from the router to the ADSL network

Router GRE -->  Provider ADSL Network  <-- Router GRE

We have a GRE tunnel running between 2 locations using this ADSL service.
Traffic over this tunnel is encrypted.

I plan to run class based weighted fair queueing outbound over the GRE
tunnels to ensure that certain traffic is guaranteed bandwidth at times of
congestion.

Proposed configuration:

class-map match-any class104
 match access-group 104
class-map match-any class103
 match access-group 103
class-map match-any class102
 match access-group 102
class-map match-any class101
 match access-group 101

(access-lists configured to match traffic)

policy-map CBWFQ
 class class101
  bandwidth percent 40
 class class102
  bandwidth percent 30
 class class103
  bandwidth percent 20
 class class104
  bandwidth percent 10

policy-map tunnel
 class class-default
  shape average [BANDWIDTH]
  service-policy CBWFQ


The idea is that the "tunnel" policy map will shape the GRE tunnel bandwidth
to a certain level, so that it knows when it is congested and will start to
queue packets, which will then be dealt with by the "CBWFQ" child policy.

- stolen pretty much wholesale from:

http://www.cisco.com/warp/public/105/qostunnel.html

My question is, what should I set the shaped bandwidth [BANDWIDTH] of the
GRE tunnel to be?

1. To the CIR of 256K of the ADSL provider
2. To the CIR of 256K + Burst of 256K = 512K
3. To the CIR of 256K plus a burst on the tunnel of 256K

As I understand it..

Option 1 will give guranteed utilisation within the ADSL providers CIR, but
will not make use of their burst facility

Option 2 would give more available bandwidth over the tunnel, with the risk
of cells being dropped in the ADSL provider network as they will be arriving
consistently above the 256K CIR and would be marked with CLP=1

Option 3 looks best on paper, but I think it would play havoc with the
cbwfq. In a given time, packets could either be queued and dealt with by
cbwfq or sent using the burst capability. 

All the documentation I can find suggests that when using cbwfq on an
interface you should remove or minimise any burst capability on the
interface.

Can anyone shed some light on the validity of these 3 options?

Thanks for your time.

Mark

 


**********************************************************************
Any opinions expressed in the email are those of the individual and not necessarily the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient.  If you are not the intended recipient or the person responsible for delivering it to the intended recipient, be advised that you have received this email in error and that any dissemination, distribution, copying or use is strictly prohibited.

If you have received this email in error, or if you are concerned with
the content of this email please e-mail to: e-security.support at vanco.co.uk

The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While the sender has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachments to this e-mail.
**********************************************************************