Re: Fragmentation in MLPPP over FR

There are two types of fragmentsto consider: FR fragments, as per FRF.12 and
PPP fragments, due to MPPP.
I think in this particular case the fragments are MPPP fragments, therefore
FRTS does not have to be enabled, and that message is a bug of some sort.
But i might be mixing IPv6 over PPPoFR, where MPPPoFR is the solution...

On Wed, Apr 15, 2009 at 5:40 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:

> Apologies for digging up an old thread (see below), but a search of
> the archives (for "FR-3-MLPOFR_ERROR") didn't really help me conclude
> the proper way to configure MLPoFR.
>
> In summary, when configuring MLPoFR, unless you have "frame-relay
> traffic-shaping" enabled on the underlying physical interfaces, you
> will receive an error like this one:
>
> %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link
> Virtual-Access3 Bundle Multilink1 :Frame Relay traffic shaping must be
> enabled
>
> However, the multilink PPP bundle comes up with the expected number of
> active links, and both links are indeed utilised. When 'ppp multilink
> interleave' is also configured, turning on debugs for 'ppp multilink
> fragments' shows that packets are distributed across each bundled
> Virtual-Access interface (not necessarily equally).
>
> So, the question is, are we going to lose points for a task where
> MLPoFR configuration is required, but FRTS is not enabled? Enabling
> FRTS by itself doesn't break anything (although as we all know, we'll
> end up with all DLCIs shaped to 56000bps), but since it doesn't seem
> to be required to bring up the bundle ....
>
> What are people's thoughts on this? Is this one of those "extra config
> doesn't hurt" times? (obviously if a subsequent QoS task requires
> FRTS, it'll have to be enabled and this becomes a moot point!)
>
> cheers,
> Dale
>
> On Sun, Jun 29, 2008 at 2:52 PM, Petr Lapukhov
> <petr_at_internetworkexpert.com> wrote:
> > Hi,
> > Technically, just for PPP *fragmentation* purpose it's not required to
> > enable FRTS with MLPPPoFR (though IOS always complains about that). From
> the
> > implementation standpoint, you need FRTS in odrer to ensure the proper
> > PVC-level dequeueing and effective *interleaving* (if you are doing it).
> > Originally, MLPPPoFR was designed to support common fragmentation and
> > interleaving scheme for FR and ATM circuits (FR-to-ATM interworking).
> Just
> > using MLPPPoFR for link *bonding* is not the best real-life idea - you
> have
> > FRF.16 to accomplish that.
> >
> > A short summary: by MLPPPoFR design you SHOULD enable FRTS and apply an
> LLQ
> > to ensure proper interleaving, but just for the task of PVC bonding it's
> not
> > REQUIRED.
> >
> > --
> > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
> > petr_at_internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> >
> > 2008/6/29 Mujeeb Sarwar <mujeebsarwar_at_gmail.com>:
> >
> >> Dear Group,
> >>
> >> I have a query regarding fragmentation in MLPPP over FR WAN setup. Let
> say
> >> we have 2 FR links between routers R2 & R3 and if task is asking for
> doing
> >> MLPPP over FR to achieve max utilization for both links and packets
> could
> >> be
> >> fragments between both links. Whenever we configure MLPPP over FR ,
> >> following message appears on console,
> >>
> >>
> >> Mar 1 00:22:42.619: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly
> on
> >> Link Virtual-Access1 Bundle Multilink1 :Frame Relay traffic shaping must
> be
> >> enabled
> >>
> >> My question is that I didn't configure traffic shaping on any interface
> >> but fragmentation is still taking place regardless of above mentioned
> >> message. So it is not must to enable traffic shaping to fullfil task's
> >> requirement ??
> >>
> >> Rack1R3#debug ppp multilink fragments
> >>
> >> Rack1R3#ping 174.1.23.2 size 1000 repeat 2
> >>
> >> Type escape sequence to abort.
> >> Sending 2, 1000-byte ICMP Echos to 174.1.23.2, timeout is 2 seconds:
> >> !!
> >> Success rate is 100 percent (2/2), round-trip min/avg/max = 88/102/116
> ms
> >> Rack1R3#
> >> *Mar 1 00:23:39.063: Vi2 MLP: O frag 80000037 size 510 encsize 6
> >> *Mar 1 00:23:39.067: Vi1 MLP: O frag 40000038 size 512 encsize 6
> >> *Mar 1 00:23:39.171: Vi1 MLP: I frag 40000033 size 510 encsize 4
> >> *Mar 1 00:23:39.171: Vi2 MLP: I frag 80000032 size 508 encsize 4
> >> *Mar 1 00:23:39.179: Vi2 MLP: O frag 80000039 size 510 encsize 6
> >> *Mar 1 00:23:39.183: Vi1 MLP: O frag 4000003A size 512 encsize 6
> >> *Mar 1 00:23:39.263: Vi1 MLP: I frag 40000035 size 510 encsize 4
> >>
> >>
> >> Regards,
> >>
> >> Mujeeb
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net