Date: Tue, 07 Sep 1999 18:05:32 +0100 From: Brian Somers <brian@Awfulhak.org> To: Rowan Crowe <rowan@sensation.net.au> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: multi chassis multi link PPP - can userland ppp do it? Message-ID: <199909071705.SAA01187@keep.lan.Awfulhak.org> In-Reply-To: Your message of "Wed, 08 Sep 1999 00:54:17 %2B1000." <Pine.BSF.4.01.9909080045180.1432-100000@velvet.sensation.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi, > > Thought I'd post this to the list rather than directly to Brian :), as it > may be of interest to others as well. > > I'm guessing that ppp doesn't currently support multi chassis multilink - > where the difference instances of the ppp 'server' do not need to be > running on the same machine. > > I'll soon be offering multilink as an option on my accounts, but there's > the possibility that a user may end up logged into separate machines even > though they're dialling the same rotary number. This is where multi > chassis comes into play... > > Any thoughts, future plans? :) I have BACP (bandwidth allocation control protocol) on my TODO list. This allows one side of the link to inform the peer how to bring up additional links. The idea is that you have a published telephone number that will connect you to an arbitrary piece of equipment, but once the link's established, ppp tells the client to use ``this number'' in future. I've read the RFC, but that's about the extent of it so far I'm afraid. The alternative is to teach ppp how to do the back-channel stuff. At the moment, ppp handles this stuff by passing the link file descriptor through a local-domain socket. This socket is named based on the peers endpoint discriminator and authentication name. This is impossible over a tcp socket :-( The cleanest way I can think of to do this sort of thing would be to have a ppp-connection service in inted.conf that was smart enough to pick up broadcast packets containing the enddisc and authname and look for the local-domain socket. If found, it fork()s and connects back to the requestor then acts as a pipe between the two.... It's a bit kludgy though :-( I'm sure the implementation would be fraught with problems. BACP/MP+ is definitely a better idea. > Also a question - what would happen if you did connect to separate > machines with identical multilink setups. I'm guessing the connect would > succeed, and you'd have an outbound (from the client end) connection > balancing over the 2 lines (and thus the 2 machines), but inbound is > anyone's guess, most of the packets coming over only one link perhaps? The client should fail when it brings up the second link, as it should be presented with two different endpoint discriminators. Unless the back-channel bit can be done, this is how things *must* be configured. If your configurations are really exactly the same, things will immediately become *very* confusing.... the client will not want to do IPCP for the second link, but the server will. When the server sends the first REQ, the client will bring down IPCP, and for identical servers, send an ACK. However, it'll also send a REQ itself. Using user-ppp, the ACK will go to one server and the REQ will go to the other..... I suspect it'd be impossible for the client to ever think IPCP was up again. > I've been playing around with a hack of iptunnel.c, which implements an > encapsulated IP tunnel, to crudely alternate the 'route' of packets > between different machines, to create a poor man's load balance. I've had > some success so far, but my programming skills aren't all that crash host. > It needs more work to be able to detect if the other end of a given IP > tunnel is down, and remove it from the list of hosts to send packets to. Sounds like MP :-) > Finally, does ppp split each packet into 2 or 3 etc then reassemble them > at the other end, or just balance links on a per packet basis? When doing > a ping the replies seem to flip back and forth between each link so I'm > guessing (again) that it's the latter. It is for user-ppp unless you've got a MRRU smaller than your MRU. An MP implementation must always be capable of reassembly though. Splitting packets seems to be a mugs game unless you can't avoid it. It would be nice to be able to combine packets, but the MP rfc doesn't allow this. > Cheers. > > > -- > Rowan Crowe http://www.rowan.sensation.net.au/ > Sensation Internet Services http://www.sensation.net.au/ > Melbourne, Australia Phone: +61-3-9388-9260 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909071705.SAA01187>