Multilink PPP FTTC No Traffic when fragmentation is active

[Jonathana13]

Background

Looking to increase bandwidth for a client with a remote site that isn't suitable for a dedicated line due to ECCs. They have FTTC installed with average speeds of 36/6 so looking to improve this using a second line.

Situation

Configured a 1921 MLPPP based on this guide (https://www.exascale.co.uk/blog/ppp-multilink-mlppp-over-vdsl-cpe-configuration/) 

Everything works fine (providing ppp multilink fragment delay is not set) when only one line is connected, bundle is showing up with one virtual interface.

As soon as the second line is connected traffic stops, very occasionally a ping makes it through so it's not a total drop but dead other than that.

Configuring ppp multilink fragment delay with just a single line causes it to drop all traffic too so working on the assumption that it's related to packet fragmentation which will obviously be enabled when the second line is active.

Have reviewed with a few other peers and double checked the config at the core and nothing jumping out as an immediate issue so any guidance would be appricaited.

[marce1000]

 - Review the available MTU's on the links and adjust to common value (achievable for both) , if needed , 

 M.

[Jonathana13]

Thanks, have just checked and links default to 1492, have tried forcing the configuration to 1492 for both connections and the multilink interface and still have the same issue.

[MHM Cisco World]

PPP multilink mrru must set. 

Why you escape this steps?

[Jonathana13]

This was set in a previous attempt but did not resolve the issue. I will re add it now. The documentation shows the values as optional though so wasn't aware it was needed.

[MHM Cisco World]

make it 1400 not 1500.

[Jonathana13]

Thanks, I tried that and encountered the same issue. I also encountered very high latency at times with it set at 1400

[MHM Cisco World]

so keep all PPP multilink command appear in link you share (include the frag delay) and add ip tcp adj 1360

[Jonathana13]

Afraid that's behaving the same. As soon as frag delay is set lose all traffic

[MHM Cisco World]

Can you share last config you test 

[Jonathana13]

Sure current config attached. Note have removed some parts for privacy.

[paul driver]

Hello
Can you clarify the xDSL circuits are from the same ISP?
Suggest also you set mtu the same across ALL interfaces(perform shut/no shut)
Can you post the output of the following:

sh ip int briief
sh controller vdsl 0/0/0
sh controller vdsl 0/1/0
sh ppp multilink
debug ppp negotiation

[Jonathana13]

Thanks Paul,

All via the same ISP and terminating at the same BNG.

Outputs attached.

Thanks

[paul driver]

Hello
The controller outputs report hight crc errors and you dsl noise signal especially for controller 0/1/0 is right on the boundary as being very poor which will cause intermittent signal synchronization or even no signal at all.

Suggest you upgrade the VDSL firmware first to the latest version  and see if this rectifies the controller issues being reported.

controller 0/0/0
Firmware Source File Name (version)
VDSL embedded VDSL_LINUX_DEV_01212008 (1)

Noise Margin: 10.9 dB 6.6 dB
Noise Margin(dB): 10.4 11.4 N/A 6.7 6.6 N/A N/A
CRC Errors: 130 130 102 102


controller 0/1/0
Firmware Source File Name (version)
VDSL embedded VDSL_LINUX_DEV_01212008 (1)

Noise Margin: 6.7 dB 6.6 dB
Noise Margin(dB): 6.6 6.8 N/A 6.5 6.7 N/A N/A
CRC Errors: 89 89 4 4
  

Also it looks like you you have PPP configuration mismatch between your rtr and the ISP regards your MRRU & MRU (MTU) values.

*Oct 14 07:30:51.610: Vi3 LCP: O CONFREQ [Starting] id 1 len 37
*Oct 14 07:30:51.610: Vi3 LCP: MRRU 1500 (0x110405DC)  <--- your sending 

*Oct 14 07:30:51.646: Vi3 LCP: I CONFREQ [REQsent] id 160 len 19
*Oct 14 07:30:51.646: Vi3 LCP: MRU 1492 (0x010405D4)  <--- your receiving

*Oct 14 07:30:51.646: Vi3 LCP: O CONFNAK [REQsent] id 160 len 8
*Oct 14 07:30:51.646: Vi3 LCP: MRU 1500 (0x010405DC) <--- your sending 

*Oct 14 07:30:51.646: Vi3 LCP: I CONFREJ [REQsent] id 1 len 31
*Oct 14 07:30:51.646: Vi3 LCP: MRRU 1500 (0x110405DC) <--- your receiving

*Oct 14 07:30:51.646: Vi3 LCP: O CONFREQ [REQsent] id 2 len 10

*Oct 14 07:30:51.650: Vi3 LCP: I CONFREQ [REQsent] id 161 len 19
*Oct 14 07:30:51.650: Vi3 LCP: MRU 1492 (0x010405D4)

*Oct 14 07:30:51.650: Vi3 LCP: O CONFNAK [REQsent] id 161 len 8
*Oct 14 07:30:51.650: Vi3 LCP: MRU 1500 (0x010405DC)
*etc.....

*Oct 14 07:30:51.674: Vi3 LCP: Sent too many CONFNAKs. Switch to CONFREJ

Edited- forgot to include example:
interface eth0
pppoe-client ppp-max-payload 1500
interface dialer 1
mtu 1492

Authentication looks okay
*Oct 14 07:30:51.678: Vi3 LCP: I CONFREQ [ACKrcvd] id 166 len 15
*Oct 14 07:30:51.678: Vi3 LCP: AuthProto CHAP (0x0305C22305)

*Oct 14 07:30:51.678: Vi3 LCP: O CONFACK [ACKrcvd] id 166 len 15
*Oct 14 07:30:51.678: Vi3 LCP: AuthProto CHAP (0x0305C22305)  

[Jonathana13]

Thanks, I will look at updating the firmware. In the mean time have adjusted the MRRU values and that has reduced the time it takes for the ppp negotiation which is good news but sadly still no traffic once there is a second connection in the bundle.