From: asadovnikov (asadovnikov@comcast.net)
Date: Wed Nov 02 2005 - 11:17:29 GMT-3
Sam,
To expand a little on Scott's good points...
In real life it is common (or at least use to be before VoIP got on the
network) to have access line procured at a higher speed then PVC CIR. The
logic behind it was that most of the time backbone of service provider is
not congested and if you can get to it your traffic would burst over CIR but
get to the other side nevertheless.
Such as in this example spoke's access line is twice of what PVC CIR is for
hub-spoke - 256/128.
Note that CIR value is end-to-end, i.e. 2 routers (hub and spoke) may have
different access line rate, but usually have same CIR as CIR is PVC based
and not router based.
(Some providers do allow asymmetric CIR settings on a PVC but you need to
have real good understanding of what is going on before you go there. If
you are doing such asymmetric provisioning you may consider going symmetric
and stay there until after you do not need to ask questions on how it all
works. In other words make all your PVCs 128 provider CIR in both
directions.)
The technical implementation then usually would be to configure traffic
shaping (on the hub side) to shape to 256 and back off on BECN to 128. This
way router bursts unless service provider network is congested and only can
pass traffic at contractually committed rate in which case router slows down
to contractually committed rate. For example
map-class frame-relay frame-shape
frame-relay cir 256000 - use access port on the
spoke
frame-relay mincir 128000 - use hub-spoke provider's
CIR
frame-relay adaptive-shaping becn
frame-relay bc 8000 - adjust as needed
frame-relay be 0 - keep at 0
On the hub side such configuration does not require p2p interface for each
spoke, although this is by far prevailing configuration in production
networks.
Similar configuration can be performed on the spoke side, except 256 shaping
would usually be not meaningful as this is what interface speed is set to
but it is not going to heart anything either.
Next point to consider is the effect of multiple spokes utilizing single hub
interface, i.e. what is going to happen if all of the spokes transmit at the
maximum at the same time, or if the hub needs to transmit to all spokes at
the same time. This is commonly solved on capacity planning side by
providing enough bandwidth on the hub access line to ensure that this would
not happen (i.e. order hub access line to equal total of spoke CIR or total
of spoke access lines). Technically such issue may also be helped a little
by using lower minCIR value on the spokes, or using interface congestion
adaptive traffic shaping on the hub - careful evaluation is needed before
using either of these 2. If you have 5 spokes at 128/256 and the hub at
5x128/1024 I would not worry about changing anything.
I have to say that some providers make queues that large to keep SLAs that
by the time you get BECN no backoff will heal congestion which makes above
discussion technically applicable but practically not helpful.
Best Regards,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Tuesday, November 01, 2005 11:04 AM
To: 'Sam Munzani'; ccielab@groupstudy.com
Subject: RE: Frame Relay traffic shaping question
For REAL LIFE stuff, consider this:
While it's nice to back off when the SP network says they're congested
(BECN/FECN), why on Earth would you choose to back off to a number less than
what you are paying for??? In your config below, you pay for 128K CIR to
the provider, yet you are telling your router it's ok to drop back to 64K
(mincir) when they complain. Yet, you still pay for it.
In your example though, you have a mathematical problem. 5 spokes at
guaranteed 128K CIR exceeds the hubs 512K CIR. Usually, PVCs are set up
where both ends have guarantees, so are you sure that your hub doesn't
really have 5 x 128K CIR's?
With mismatched numbers, you're going to find that things don't quite add up
nicely and may take some playing with based on what applications you're
running and where they're going to. I would suggest though, that you adjust
the CIR you are actually paying for, knowing that you can burst above that
speed (SP burst, not your own configured burst) but don't back down less
than what you are guaranteed. That may mean adjusting your bill a bit.
FRTS is what you want to achieve. BECN's, FECN's and mincir is the bare
minimum that you will achieve from the SP standpoint (what you are truly
paying for in SP-based CIR).
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Sam
Munzani
Sent: Tuesday, November 01, 2005 10:45 AM
To: ccielab@groupstudy.com
Subject: Frame Relay traffic shaping question
What's best approach for frame-relay traffic shape in following
configuration?
Hub (1024K line, 512K CIR)
|
------------------------------------------
| | | | |
Site A B C D E
All remote sites are 256K line speed with 128K CIR.
Here is my dilemma,
If I configure following parameters at all sites, the hub site will start
shaping when it reaches 128K. If I configure hub site with 512K of CIR, it
can saturate remote site since remotes are small CIR.
map-class frame-relay frame-shape
frame-relay cir 128000
frame-relay mincir 64000
frame-relay adaptive-shaping becn
frame-relay bc 8000
frame-relay be 16000
Here is the approach I am thinking of:
1. Configure hub with sub interfaces.
2. Have sub interface parameters match remote site paramters.
Does it make sense? Any better option?
Thanks,
Sam
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:04 GMT-3