Stefanus writes:
> I'm configuring a PPP server and it is able to accept multiple client
> connections. Each connected client is handled by a PPP virtual
> interface, for example if 10 clients connected then there'll be
> ppp0-ppp9 on the server.

Yes.

> I'm curious, is it possible to aggregate these virtual interfaces into
> a single interface? Therefore the server only need to maintain ppp0
> for multiple clients. If so, how to configure it?

I don't understand. Aren't these 10 *different* clients? If so,
aren't these 10 links to completely different IP nodes? How will
routing work if you have a single IP interface that goes to distinct
destinations?

I can think of two scenarios here. The first is that these aren't
distinct clients, and you've got 10 links between two nodes. In this
case, Multilink PPP (MP) would work, but I'd caution against the use
of MP on virtual links. The latency of the overall link is the
*worst* of all latencies on the member links, and the loss rate is
(also roughly) the sum of all loss rates, and that's usually
unacceptable on virtual links.

The second scenario is that all these clients are proxy ARP'd and you
want to collect them into some sort of logical IP subnet. Even then,
I'm not sure the question makes sense. Suppose you have two servers
for load spreading or redundancy: what would you do then? It sounds
sort of remotely feasible if you have kernel source code for your
operating system and a *LOT* of spare time on your hands, but probably
not the most usable solution.

(In particular, what would you do about the aggregated MTUs?)

> If not possible, would the server be scalable? Because if 1000 clients
> are connected, the server would have to maintain ppp0-ppp999, would it
> cause any problem?

That depends on the system you're using. You didn't mention what sort
of system you're using, nor what software, nor what scaling issues
you're concerned about.

It's probably not possible to answer the question as asked.

--
James Carlson, KISS Network
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

Hi James,
thank you very much for clearing that up.

James Carlson wrote:
>>If not possible, would the server be scalable? Because if 1000 clients
>>are connected, the server would have to maintain ppp0-ppp999, would it
>>cause any problem?
>
>
> That depends on the system you're using. You didn't mention what sort
> of system you're using, nor what software, nor what scaling issues
> you're concerned about.
>
I'm using FC3 and PPP-2.4.2 equipped with ppp-radius and ppp-dhcp plugin.

-Stefanus

Stefanus writes:
> James Carlson wrote:
> >>If not possible, would the server be scalable? Because if 1000 clients
> >>are connected, the server would have to maintain ppp0-ppp999, would it
> >>cause any problem?
> > That depends on the system you're using. You didn't mention what
> > sort
> > of system you're using, nor what software, nor what scaling issues
> > you're concerned about.
> >
> I'm using FC3 and PPP-2.4.2 equipped with ppp-radius and ppp-dhcp plugin.

That's really not enough information.

What scaling problems are you worried about? Are you running routing
daemons? How about network management software? Or multicast
applications (or others that attempt to bind every interface)?

Is it CPU load, or memory pressure, or I/O waits, or something more
exotic (such as lock contention or cache thrashing) that's at issue?
Or is it a concern about poor application algorithms (e.g., an SNMP
daemon with a simple linked-list of interfaces and O(N^2) or worse
lookup mechanisms)?

For what it's worth, each link will need to be negotiated separately
per the PPP standards, so aggregating them into a single "ppp0"
interface (if that's even possible; it looks like a lot of work to me)
will have no effect at all on either ppp-2.4.2 or the plugins you're
using or the backend authentication (RADIUS) and address assignment
(DHCP) mechanisms you have. The information about that software
doesn't appear relevant to the problem, at least based on the proposed
solution.

Scaling problems come in all shapes and sizes, and attempting to
predict the sorts of problems you might face based on just the OS or
rough information about _some_ of the software won't do. Either read
the code and attempt to extrapolate the issues (always fraught with
peril), or set up some test cases and _measure_ the metrics of
interest.

--
James Carlson, KISS Network
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677