Multilink PPP Download Speeds With Round-Robin Packets

[Alexander Motin]

Hi.

Michael MacLeod wrote:
> On Jan 16, 2008 5:21 PM, Alexander Motin <mav at freebsd.org> wrote:
>> Mpd supports both. There were some mistakes in multilink transmission
>> part of ng_ppp kernel module working in splitting mode that in some
>> cases could lead to ineffective packet distribution, but they were fixed
>> 8 months ago at 6-STABLE.
> 
> I updated my gateway using freebsd-update, and rebuilt my kernel after
> making sure I had the latest sources. I proceeded to install mpd4 and
> try out the configuration Nikos linked to. So far I haven't had any
> success. I tried adding 'set bundle enable round-robin' since that's
> how this is going to work on the download side of things, still
> without success.
> 
> mpd.conf:
> ------------------------------------------------------------
> startup:
>         set console ip 127.0.0.1
>         set console user username password
>         set console open
> 
> default:
>         load PPPoE
>         open
> 
> PPPoE:
>         new -i ng0 sam l0 l1
>         set auth authname username at teksavvy.com
>         set auth password password
>         set bundle enable multilink
>         set bundle enable round-robin
>         set iface idle 0
>         set iface route default
> ------------------------------------------------------------

This config is not completely correct for multilink case since 
mpd-4.0rc1 due to changes:
  - Auth configuration (set auth ...) moved from bundle layer to lcp. It 
works per link now.
  - Default argument of open/close commands changed from iface to lcp.

I would recommend you something like:

default:
         new sam l0 l1
         set bundle enable multilink
         set bundle enable round-robin
         set iface route default
	
	link l0
         set auth authname username at teksavvy.com
         set auth password password
	set link max-redial 0
	open
	
	link l1
         set auth authname username at teksavvy.com
         set auth password password
	set link max-redial 0
	open

> and finally, the log file:
> ------------------------------------------------------------
> Jan 19 16:34:26 gateway mpd: [l0] LCP: rec'd Configure Request #237 (Req-Sent)
> Jan 19 16:34:26 gateway mpd:  MRU 1492
> Jan 19 16:34:26 gateway mpd:  AUTHPROTO PAP
> Jan 19 16:34:26 gateway mpd:  MAGICNUM 4e7ea6a0

Your peer looks very interesting. The first thing it does is not 
announcing multilink capabilities.

> Jan 19 16:34:26 gateway mpd: [l0] LCP: rec'd Configure Reject #1 (Ack-Sent)
> Jan 19 16:34:26 gateway mpd:  MP MRRU 1600
> Jan 19 16:34:26 gateway mpd:  MP SHORTSEQ
> Jan 19 16:34:26 gateway mpd:  ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b

Than it rejects mpd's multilink options negotiations.

> Jan 19 16:34:26 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened
> Jan 19 16:34:26 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing
> Jan 19 16:34:26 gateway mpd: [l0] PAP: using authname "username at teksavvy.com"
> Jan 19 16:34:26 gateway mpd: [l0] PAP: sending REQUEST len:33
> Jan 19 16:34:26 gateway mpd: [l0] LCP: LayerUp
> Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Request #0 (Opened)
> Jan 19 16:34:27 gateway mpd:  MRU 1492
> Jan 19 16:34:27 gateway mpd:  MP MRRU 32719
> Jan 19 16:34:27 gateway mpd:  ENDPOINTDISC [LOCAL] 34 36 30 37 32 31
> 30 30 39 34 00 00 00 00 00
> Jan 19 16:34:27 gateway mpd:  AUTHPROTO PAP
> Jan 19 16:34:27 gateway mpd:  MAGICNUM 5ec55af5

At this moment call probably passed from access concentrator (probably 
LAC) to access server (probably LNS). LNS in difference to LAC advertise 
miltilink support.

> Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerDown
> Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigReq #3
> Jan 19 16:34:27 gateway mpd:  PROTOCOMP
> Jan 19 16:34:27 gateway mpd:  MRU 1492
> Jan 19 16:34:27 gateway mpd:  MAGICNUM 6a64dffc
> Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigNak #0
> Jan 19 16:34:27 gateway mpd:  MP MRRU 1600
> Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Opened --> Req-Sent
> Jan 19 16:34:27 gateway mpd: [l0] AUTH: Cleanup
> Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Nak #3 (Req-Sent)
> Jan 19 16:34:27 gateway mpd:  MP MRRU 32719
> Jan 19 16:34:27 gateway mpd:  ENDPOINTDISC [NULL]
> Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigReq #4
> Jan 19 16:34:27 gateway mpd:  PROTOCOMP
> Jan 19 16:34:27 gateway mpd:  MRU 1492
> Jan 19 16:34:27 gateway mpd:  MAGICNUM 6a64dffc

After peer rejected multilink once, mpd is not trying to negotiate it 
any more. I am not sure it is a correct behaviour, but Cisco manuals 
recommend to configure LAC in a way that avoids rejections.

User-land ppp seems to have specific workaround for this case while mpd 
does not. I don't very like this idea, but probably I could add this if 
you like to test it.

> Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened
> Jan 19 16:34:27 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing
> Jan 19 16:34:27 gateway mpd: [l0] PAP: using authname "username at teksavvy.com"
> Jan 19 16:34:27 gateway mpd: [l0] PAP: sending REQUEST len:33
> Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerUp
> Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Terminate Request #2 (Opened)

Why peer rejected you after second authentication without any reply is a 
question to your provider.

Second link in your case even has not tried to connect.

-- 
Alexander Motin