Date: Sun, 20 Jan 2008 00:23:20 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Michael MacLeod <mikemacleod@gmail.com> Cc: freebsd-net@freebsd.org, Julian Elischer <julian@elischer.org>, Nikos Vassiliadis <nvass@teledomenet.gr> Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets Message-ID: <47927858.4050702@FreeBSD.org> In-Reply-To: <e8f0b580801191347y42b3a041y821dc4d8805a168b@mail.gmail.com> References: <1200479046.00010232.1200466203@10.7.7.3> <1200479105.00010249.1200468002@10.7.7.3> <1200482587.00010258.1200469801@10.7.7.3> <1200489793.00010290.1200478201@10.7.7.3> <1200518607.00010486.1200507002@10.7.7.3> <478E834E.4080302@FreeBSD.org> <e8f0b580801191347y42b3a041y821dc4d8805a168b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi.
Michael MacLeod wrote:
> On Jan 16, 2008 5:21 PM, Alexander Motin <mav@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@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@teksavvy.com
set auth password password
set link max-redial 0
open
link l1
set auth authname username@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47927858.4050702>