From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Mon Jun 09 2003 - 05:32:19 GMT-3
OK thats cool.... But back to my question.... Or let me rephrase.... when does the link become diassembled from the bundle? I'm looking for answers to my examples below..
Anyone?
Daniel
-----Original Message-----
From: John Underhill [mailto:stepnwlf@magma.ca]
Sent: Monday, 9 June 2003 09:54
To: Daniel Cisco Group Study; ccielab@groupstudy.com
Subject: Re: Dialer Load Threshold - When does it come back down???
As the pipe gets full, it dials a second bri, creating the MP bundle, the
dialer load-threshold is the criteria it uses to determine when an MP should
be created, and additional lines brought into the bundle, (say, in the case
of a PRI). When the flow falls below the defined threshold the bundle is
dissasembled and the secondary bri is left idle. After the idle-timeout is
reached, it drops the bri.
From the rfc:
http://www.ietf.org/rfc/rfc1717.txt
Implementations concerned about either wasting bandwidth or per packet costs
are not required to send null fragments and may elect to defer sending them
until a timer expires, with the marginally increased possibility of
lengthier stalls in the receiver. The receiver SHOULD implement some type
of link idle timer to guard against indefinite stalls.
----- Original Message -----
From: "Daniel Cisco Group Study" <danielcgs@imc.net.au>
To: "John Underhill" <stepnwlf@magma.ca>; "Daniel Cisco Group Study"
<danielcgs@imc.net.au>; <ccielab@groupstudy.com>
Sent: Sunday, June 08, 2003 7:11 PM
Subject: RE: Dialer Load Threshold - When does it come back down???
> I don't think so. In ppp multilink environment, packets are fragmented
across multiple B channels. It would be highly unlikely that any B channels
would be quite, while others are busy.
>
> Daniel
>
>
> -----Original Message-----
> From: John Underhill [mailto:stepnwlf@magma.ca]
> Sent: Monday, 9 June 2003 01:56
> To: Daniel Cisco Group Study; ccielab@groupstudy.com
> Subject: Re: Dialer Load Threshold - When does it come back down???
>
>
> Doesn't this depend on the dialer idle-timeout setting? If any one of the
> cumulative links is idle beyond the defined time it will drop, and redial
if
> the load threshold is reached again..
>
> ----- Original Message -----
> From: "Daniel Cisco Group Study" <danielcgs@imc.net.au>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, June 08, 2003 2:36 AM
> Subject: Dialer Load Threshold - When does it come back down???
>
>
> > This whole issue is very unclear in my mind. The docos say the
following:
> >
> > "When the cumulative load of all UP links (a number n) exceeds the load
> threshold the dialer adds an extra link and when the cumulative load of
all
> UP links minus one (n - 1) is at or below load threshold then the dialer
can
> bring down that one link. The dialer will make additional calls or drop
> links as necessary but will never interrupt an existing call to another
> destination"
> >
> > I would like to work on a couple of examples with those who are
> interested.
> >
> > (1) Say I use the following:
> >
> > int bri 0
> > ppp multilink
> > dialer load-threshold 64 either
> >
> > I think that we would all agree that the 2nd B channel comes up when the
> load in either direction on the active (1st) B channel reaches 16kbps.
(64k
> x [64/255]).
> >
> > Now, when does it come back down ???? The doco tries to explain it, but
> its all very muddy in my mind.... I don't know what its trying to say.
> >
> >
> > (2) Let's take this one step further.
> > We have an E1 PRI service (30 channels + 1D) - placing calls to the same
> destination:
> >
> > int s0/0:15
> > ppp multilink
> > dialer load-threshold 64 either
> >
> > We would agree that if we already have 5 B channels up, the 6th one
comes
> up when the combined bandwidth of all 5 B channels is 80k (5 x 64 x
> [64/255]). Correct ?????
> >
> > Now we have 6 B channels for a combined total available bandwidth of
384k.
> When does one of the B channels drop?
> >
> > Daniel
> >
> >
> >
> >
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> > This footnote also confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> > www.mimesweeper.com
> > **********************************************************************
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> www.mimesweeper.com
> **********************************************************************
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:55 GMT-3