[c-nsp] Multilink PPP incorrect weights

Alberto Cruz alberto.cruz at execulink.com
Fri Nov 30 15:49:23 EST 2012


Hello good afternoon. I found these thread and it looks that there wasn't a final resolution for it.

I am experiencing the same issue. I have posted a new thread since I hadn't found a similar one until now.

We have been working to deploy a MLPPP bundle solution for ADSL using Cisco platform. We have a Cisco 7301 as LNS and Cisco 891 as CPE.

We have facing some challenges because we don't have the control over the ADSL network; the ADSL is delivered by Bell Canada.
Therefore, we could receive a mix of ADSL services in fast-path mode or interleaving mode.

We are aware now that the LNS sets the multilink weight of each member according in what it receives from the LAC. Moreover, we know disabling fragmentation on the MLPPP template allows to bundle the downstream bandwidth for links with different speed.
Despite we can achieve the sum of the speed of the links, fragmentation errors at the CPE increase dramatically.
**** Log from CPE ****
Nov 29 18:26:46.712: Vi4 MLP: Lost fragment 51E9 (RX buffer overflow), new seq 51EA
Nov 29 18:26:46.712: Vi4 MLP: Discard reassembled packet
Nov 29 18:26:46.716: Vi4 MLP: Received lost fragment seq 51A5, expecting 51EB
Nov 29 18:26:46.716: Vi4 MLP: Lost fragment 51EB (RX buffer overflow), new seq 51EC
Nov 29 18:26:46.716: Vi4 MLP: Discard reassembled packet
Nov 29 18:26:46.716: Vi4 MLP: Lost fragment 51ED (RX buffer overflow), new seq 51EE
Nov 29 18:26:46.716: Vi4 MLP: Discard reassembled
Nov 29 18:26:46.724: Vi4 MLP: Lost fragment 51F5 (RX buffer overflow), new seq 51F6
Nov 29 18:26:46.724: Vi4 MLP: Discard reassembled packet
Nov 29 18:26:46.724: Vi4 MLP: Received lost fragment seq 51AF, expecting 51F7
Nov 29 18:26:46.728: Vi4 MLP: Lost fragment 51F7 (RX buffer overflow), new seq 51F8
Nov 29 18:26:46.728: Vi4 MLP: Discard reassembled packet
Nov 29 18:26:46.728: Vi4 MLP: Received lost fragment seq 51B1, expecting 51F9

It seems, the difference in the latency at each links produce this behavior.

Is there a way to fix the fragmentation errors?


Oliver replied in 2005 that he couldn't find a way to overwrite/ignores the receive RX-speed.

Has Cisco supplied a new command or procedure to overwrite the weights on multilink members?

Regards

Alberto





More information about the cisco-nsp mailing list