Re: Fragmentation in MLPPP over FR

From: Dale Shaw <dale.shaw_at_gmail.com>
Date: Wed, 15 Apr 2009 13:40:33 +1000

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
Received on Wed Apr 15 2009 - 13:40:33 ART

This archive was generated by hypermail 2.2.0 : Mon May 04 2009 - 07:39:12 ART