Date: Wed, 8 Sep 1999 12:30:39 +0100 From: Josef Karthauser <joe@pavilion.net> To: Brian Somers <brian@Awfulhak.org> Cc: Rowan Crowe <rowan@sensation.net.au>, freebsd-isp@FreeBSD.ORG Subject: Re: multi chassis multi link PPP - can userland ppp do it? Message-ID: <19990908123038.F87425@florence.pavilion.net> In-Reply-To: <199909071705.SAA01187@keep.lan.Awfulhak.org> References: <Pine.BSF.4.01.9909080045180.1432-100000@velvet.sensation.net.au> <199909071705.SAA01187@keep.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 07, 1999 at 06:05:32PM +0100, Brian Somers wrote: > > 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. > This has limited scope however with ISPs, cos they tend to have a single number distributed across multiple boxes which don't have their own individual numbers available. We have to rely on a vendor specific methodology for managing the multichassisness, Ascend "stack" for instance. > 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. There is also the question of how routes get advertised on the network behind the ppp server. Ideally only once of the multiple ppp servers should advertise for the network, and the other should slave off this one. i.e. a user logs into two separate boxes with a 64k channel each. One of the boxes (the first one normally) established the connection and advertise the route. When the second call come in to a different box the two ppp servers negotiate a "bundle" between them and the first box (which has got the route to the network) distributes the packets fairly between itself and the other ppp server. [...] > 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. Cisco boxes can perform the dynamic splitting of packets through a tunnel so that the MTU of the link can be artificially raised to compensate for the extra packet header enforced by the encapsulated link. This needs to happen because lots of sites are configured incorrectly to filtered ICMP-MustFragment packets. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] 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?19990908123038.F87425>