Re: Bandwidth 1544 vs 1536

From: Ahmed Mustafa (ahmed.mustafa@sbcglobal.net)
Date: Sun Apr 11 2004 - 19:45:17 GMT-3


Howard,

Thanks for good expalanation. About the Task, it is not that they are
asking to do unequal cost load balance between 1536 and 64. I didn't
explain the whole task.

All I meant to ask if the Task states that do a unequal cost load balance
between full T1 and the other link is Frame-Relay with bandwidth 786.

Now Obviously, in a lab enviroment, I will have to change my Frame-Realy
bandwidth from default 1544 to 768.

What about the T1 link bandwidth. All it is stating Full T1. Should it be
left it alone with 1544 or should it be changed to 1536. In a solution for
this specific task, the bandwidth was changed from 1544 to 1536.

Thanks,

Ahmed
----- Original Message -----
From: "Howard C. Berkowitz" <hcb@gettcomm.com>
To: <ccielab@groupstudy.com>
Sent: Sunday, April 11, 2004 2:54 PM
Subject: Re: Bandwidth 1544 vs 1536

> At 2:28 PM -0700 4/11/04, Ahmed Mustafa wrote:
> >What is the correct way to interpret Serial interface bandwidth.
Usually, it
> >is said that by default Serial interface bandwidth is equivalent to T1
> >bandwidth.
> >
> >It doesn't seem to be correct since the T1 bandwidth is 1536000 64000KB
x 24
> >Channels, and the serial port bandwidth is 1544000.
>
> No. The bandwidth of a T1 is 1544000. Its payload is 1536000. Cisco
> _generally_ considers bandwidth equivalent to 1/bit time, whether the
> clocking is internal or external. See the exception below.
>
> >
> >Two Questions:
> >
> >1) If the tasks states the T1 bandwidth so should we change the serial
port
> >bandwidth from 1544 to 1536 or leave it alone.
>
> The bandwidth is 1544, which happens to be the default bandwidth for
> a Cisco serial port.
>
> >
> >2) In a lab environment, we usually use DCE/DTE cable and whatever the
> >clockrate is configured for it that fast the link would be then. If I
> >configure my clock rate 64000KB then it is obvious that the DCE/DTE would
be
> >sending bits at the rate of 64000 bits per second regardless of what the
> >bandwidth parameters are set for.
>
> There is no automatic linkage between bandwidth and clockrate. This
> is the exception I mentioned below. It is common practice to force an
> artificially low bandwidth parameter on a link to make it less
> preferred.
>
> That will distort the throughput measurements in show and SNMP
> information, but, if you know you are artificially setting the
> bandwidth, your analysis software can correct throughput.
>
> >
> >I am confused how I would actually configure unequal cost load-balancing
for
> >EIGRP.
> >
> >The task states to use the T1 bandwidth so I must change the default
serial
> >bandwidth from 1544 to 1536, but the clock rate I configured is only
64000KB.
> >The question how should I go about configuring load-balancing by keeping
> >everybody happy.
> >
>
> Who came up with this task? Changing 1544 to 1536 is silly. The 8Kbps
> difference is lost in the noise with any EIGRP variance setting.
>
> In real-world practice, having one link at 1544 and one at 64 will
> give truly terrible performance, especially with respect to
> out-of-sequence packets.
>
> Even Cisco's general rule is not to do unequal cost per-packet with
> links having a variance of more than 2 or 3. With a variance of 24,
> in the scenario you describe, the difference in per-bit propagation
> delay becomes more important to protocols than speed alone.
>
> Per-packet unequal cost load balancing is really a last-resort tool
> -- realistically, it seemed like a good idea when IGRP was first
> developed, but has been shown operationally to often be more trouble
> than it's worth. If you do source-destination load balancing,
> possible with CEF, it's a little better.
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:46 GMT-3