From: ccie2be (ccie2be@nyc.rr.com)
Date: Sat Jul 31 2004 - 07:57:25 GMT-3
Geert,
These are each great questions and very apropro of the recent discussions
that have been going on here. I look forward to hearing lots of responses.
I wish I knew the answers but the only answer I'm very confident of is for
the 1st question.
The load is based on only the utilization of the 1st channel, not both
channels.
For the 2nd question, I believe it's not necessary to explicitly specify
bandwidth 128 for things to work properly, but I can see no harm in doing
so. There's also the added benefit of specifying the bandwidth explicitly
if you're running ospf over the circuit in that with the bandwidth
explicitly specified, you won't have ospf consider that a topology change
has occured when the 2nd channel comes up or goes down making ospf's
topology table more stable.
Also, I believe that the bandwidth 128 command does NOT affect the
dialer load-threshold operation. Dialer load-threshold works at either
layer 1 or 2 while the bandwidth command works at layer 3 - it's used by
routing protocols to determine cost.
However, a common myth that the bandwidth is only used by routing protocols
is NOT true. It also affects a number of QoS functions, but let's not go
there right now.
HTH, Tim
----- Original Message -----
From: "Geert Nijs" <geert.nijs@simac.be>
To: "Richard Dumoulin" <richard.dumoulin@vanco.es>; "James"
<james@towardex.com>
Cc: <ccielab@groupstudy.com>; "Scott Morris" <swm@emanon.com>;
<laurent.metzger@bt.com>; "Elliott Reyes" <elliottreyes@adelphia.net>
Sent: Saturday, July 31, 2004 5:21 AM
Subject: SUBJECT CHANGE
> Please take this discussion off-line and change the subject, because i
DON'T LIKE that this discussion is made under my CCIE number.....
>
> Enough.
>
> Lets concentrate on what this forum is really for: discussing technical
questions, like for example the following one, which i posted recently, but
haven't received any answers yet:
>
>
> * When configuring "dialer load-threshold" on a PHYSICAL BRI0/0 interface,
what bandwidth does this reference to ??
> The physical interface bandwidth or one B-channel bandwidth ?
>
> I have noticed that the default bandwidth of "int BRI0/0" AND "int
BRI0/0:1" AND "int BRI0/0:2" are all 64 kbps.
>
> 1) MUST we specify "bandwidth 128" under "int bri0/0" ? (i think i have
read this somewhere in Packet Magazine0)
> Isn't this a better representation of the real available bandwidth ? (like
when you are running ospf over it)
> This statement leaves the bandwidth on the B-channels to 64 kbps, i have
verified that.
>
> 2) If "bandwidth 128" is specified under the physical interface, does this
influence the "dialer load-threshold"
> calculation ??? Or when a connection is made is this calculation based
> under the load of the B-channel (BRI0/0:1 or 2). If so, how do i
> change the bandwidth of a B-channel, if at all possible ?
>
>
> Geert
> CCIE #13729
>
> -----Oorspronkelijk bericht-----
> Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Richard
Dumoulin
> Verzonden: zaterdag 31 juli 2004 1:18
> Aan: James
> CC: ccielab@groupstudy.com
> Onderwerp: RE: CCIE #13729
>
> James,
>
> While unsolicited (just kidding) I do appreciate the lesson in sales.
You're
> obviously well versed in it and you convinced me. What I do not appreciate
> so much is seeing how people "publicly" ruin John's reputation instead of
> unicasting him an e-mail,
>
> --Richard
>
> -----Original Message-----
> From: James [mailto:james@towardex.com]
> Sent: viernes, 30 de julio de 2004 23:33
> To: Richard Dumoulin
> Cc: ccielab@groupstudy.com
> Subject: Re: CCIE #13729
>
>
> Richard,
>
> On Fri, Jul 30, 2004 at 10:13:22PM +0100, Richard Dumoulin wrote:
> > Here everyone advertises so why not John ? When someone posts a
question
> > related to his product and the vendor answers he is indirectly
> > advertising too. I have not seen you complain,
>
> There is a difference between "opt-in" and "unsolicited" advertisement.
>
> A good sales person will follow a good net etique when it comes to selling
> products & services via a mailing list such as:
>
> o Not sending unsolicited commercial oriented advertisements to broadcast
> list.
> o Unicasting "opt-in" requested indirect advertisements/replies to the
> requestor via off-list method in private; unless of course many number
of
> people have requested it, in which a broadcast to public mailing list
may
> help, dependent on list's AUP policies.
> o Understand that people in general do not appreciate cold calls whether
> the
> intent is to help or sell especially when it is unsolicited sales
pitch.
> In such case, unicast off-list email is a better judgement.
>
> And no, I am not saying John is a bad sales person, nor am I publicly
> denouncing his name on purpose. This is all common sense to net sales.
> People from time to time make mistakes, and from time to time are not
aware
> of best common practices out there to conduct a task (including myself
> definately, don't get me wrong).
> It is not a problem in general so long as they realize the inconvenience
and
> improve upon the realization.
>
> -J
>
> >
> > --Richard
> >
> --
> James Jun TowardEX
Technologies,
> Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
> _______________________________________________________________________
> 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
>
>
> **********************************************************************
> 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@vanco.info
>
> 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.
> **********************************************************************
>
> _______________________________________________________________________
> 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
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.732 / Virus Database: 486 - Release Date: 29/07/2004
>
>
############################################################################
#########
> This e-mail and any attached files are confidential and may be legally
privileged.
> If you are not the addressee, any disclosure, reproduction, copying,
distribution,
> or other dissemination or use of this communication is strictly
prohibited.
> If you have received this transmission in error please notify Simac
immediately
> and then delete this e-mail.
>
> Simac has taken all reasonable precautions to avoid virusses in this
email.
> Simac does not accept liability for damage by virusses, for the correct
and complete
> transmission of the information, nor for any delay or interruption of the
transmission,
> nor for damages arising from the use of or reliance on the information.
>
> All e-mail messages addressed to, received or sent by Simac or Simac
employees
> are deemed to be professional in nature. Accordingly, the sender or
recipient of
> these messages agrees that they may be read by other Simac employees than
the official
> recipient or sender in order to ensure the continuity of work-related
activities
> and allow supervision thereof.
>
############################################################################
#########
>
> _______________________________________________________________________
> 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 : Sun Aug 01 2004 - 10:12:07 GMT-3