From: Jelle Borsje (borsjej@yahoo.dk)
Date: Wed Apr 13 2005 - 06:00:58 GMT-3
Hej,
The command-reference, as often is the case, reveals a
bit more information about this. Looking through the
list of commands related to MFR, I find the following:
"frame-relay multilink output-threshold". And the
usage guidelines with it shed some more light on how
this works:
"Multilink Frame Relay enables load balancing across
bundle links that are in the same bundle. When a
bundle link has reached its output threshold,
transmission rolls over to the next available bundle
link in the bundle."
The default output threshold is 300 bytes, which
means, MFR starts using the next bundle-link after it
has transmitted 300 bytes. I am assuming it's rotating
through the bundle-links, and uses the next available
one.
Another interesting thing when you change the queueing
type:
"The output threshold mechanism applies only when the
bundle interface is using FIFO output queueing. When
the bundle interface is not using FIFO output queuing,
the algorithm for choosing a bundle link interface for
output selects the bundle link with the empty or
shortest output queue."
So, when FIFO is not configured, it will simply
transmit on the bundle-link with the shortest output
queue...
It is still not a watertight explanation... but makes
it a bit clearer then it was was before.
Hope this helps ;-)
Greetz
Jelle
--- ccie2be <ccie2be@nyc.rr.com> skrev:
> Sean,
>
> As I said, I don't think there's a dlci issue if one
> of the pvc's fails.
>
> This is because with multilink the Layer 3 interface
> is virtual - the ip
> address is on the multilink interface, not the f/r
> interface.
>
> Therefore, when the router has packets to send to
> the other side of the
> multilink, it does the layer 3 to layer 2 resolution
> and finds one of the
> pvc's and sends the packet. If both pvc's are up, I
> don't know how the
> router decides which pvc to use but if one of the
> pvc's goes down, then
> there's no choice and the router will use that one.
>
> Does this make sense?
>
> But, what's an interesting question and one I don't
> know the answer to is:
>
> When more than one link in the multilink bundle can
> be used, which link is
> used?
>
> Does the router load balance? If so, how?
>
> Food for thought.
>
> Tim
>
> -----Original Message-----
> From: Sean C [mailto:Upp_and_Upp@hotmail.com]
> Sent: Tuesday, April 12, 2005 5:10 PM
> To: Mark Lasarko; ccielab@groupstudy.com;
> ccie2be@nyc.rr.com
> Subject: Re: Realworld use of Multilink Frame Relay
>
> Thanks Mark. So it looks like the resiliency is
> really only if the DLCIs
> are provisioned on both T1s.
>
> I'll let you know how it looks when we install some
> next week.
> Sean
> ----- Original Message -----
> From: "Mark Lasarko" <mlasarko@co.ba.md.us>
> To: <ccielab@groupstudy.com>;
> <Upp_and_Upp@hotmail.com>;
> <ccie2be@nyc.rr.com>
> Sent: Tuesday, April 12, 2005 1:02 PM
> Subject: Re: Realworld use of Multilink Frame Relay
>
>
> > Greetings Sean,
> >
> > I share Tim's understanding.
> > I also "confirmed" this from our service provider.
> > I have to leave that in quotes as they often leave
> me
> > reason to question their advice and guidance at
> times.
> >
> > I am under the impression that if you lose a link
> you
> > just lose that portion of your aggregate
> bandwidth.
> > (So watch your QoS configs) And the down DLCI's
> don't
> > get moved to another bundle... They're simply
> unavailable.
> > The MFR Link Integrity Protocol messages handle
> the part
> > that adds and removes links as they come and go.
> >
> > Have you read the forum doc on this?
> > http://www.mplsforum.org/frame/frfia.shtml
> >
> > I do interpret Cisco's "Service Resilience When
> Links Fail"
> > statement as being more market-esque than literal
> though...
> >
> > That said, I still get the blank stare response
> when I enquire
> > about this more often than not. Seems a lot of
> well-seasoned
> > engineers don't know too much if anything about
> this
> >
> > And don't bother asking sales about this unless
> you like responses
> > like
> > "You want to do what???"... <silence>... "What was
> that again??"
> >
> >
> > As for me, I guess I better lab it up :)
> >
> > I would be very interested to hear more from
> others on this.
> > I have been considering bundling links from
> multiple providers,
> > granted the transit deltas are similar, of course.
> >
> > Best,
> > ~M
> >
> >
> >>>> "Sean C" <Upp_and_Upp@hotmail.com> 4/12/2005
> 11:36:09 AM >>>
> >
> > Hi Tim,
> >
> > One of the mentioned reasons for Multilink Frame
> is (per CCO): Greater
> >
> > Service Resilience When Links Fail - Greater
> service resilience is
> > provided
> > when multiple physical interfaces are provisioned
> as a single bundle.
> > When a
> > link fails, the bundle continues to support the
> Frame Relay service by
> >
> > transmitting across the remaining bundle links.
> >
> > So, if using Multilink FR, and using the scenario
> I mentioned below:
> > unless
> > both T1s are advertising all DLCIs, how will the
> carrier let a circuit
> > carry
> > non-native DLCIs. IOW, from my example below, if
> the 2nd T1 fails, how
> > does
> > the carrier allow the 1st T1 to handle DLCIs 4, 5,
> 6. Won't DLCIs 4, 5
> > and
> > 6 need to be configured on the 1st T1. I can't
> just hope the carrier
> > knows
> > to allow DLCIs 4, 5 and 6 on the 1st T1. What
> happens now if I tried
> > to
> > configure DLCIs on a circuit where they are not
> provisioned - nothing.
> > So,
> > how does the carrier carry all DLCIs. Do both
> circuits need to carry
> > all 6
> > DLCIs? Or, from what Jaffe mentioned in a
> different email, the carrier
> > is
> > also responsible for creating a virtual interface
> on their equipment
> > and all
> > DLCIs ride on the Virtual interface, not on the
> physical circuits.
> >
> > Hope this makes sense and appreciate your
> comments,
> > Sean
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "'Sean C'" <Upp_and_Upp@hotmail.com>; "'Group
> Study'"
> > <ccielab@groupstudy.com>
> > Sent: Tuesday, April 12, 2005 11:13 AM
> > Subject: RE: Realworld use of Multilink Frame
> Relay
> >
> >
> >> I'm not sure I completely understand your
> question, but if I do, it
> > seems
> >> to
> >> me that multilink is independent of how the f/r
> switches behave.
> >>
> >> The way I think of it, multilink is to serial
> interfaces what
> > etherchannel
> >> is to ethernet links - it's just a way to
> aggregate links. I don't
> > think
> >> or
> >> see any reason for the behavior of the f/r
> switches to do anything
> >> differently just because you decided to aggregate
> multiple links
> > running
> >> f/r
> >> encap.
> >>
> >> Of course, the routers on each side have to know
> what's
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:57 GMT-3