VDS PPPoE question

[markscs]

I don't want to add any fuel-to-the-fire with the bridge-vs-route religion war thing, BUT...

Could I route all of my APs on my wireless network, then set up a massive VDS system between all of the customer-facing WPCI interfaces and an interface back at the NOC so that all of my customers could authenticate via PPPoE (to a LAC at the NOC, not via the StarOS PPPoE server at each AP) and I can control all the authentication, address assignment (customer can keep static IP if I move them to a different sector/whatever as I scale the network), bandwidth control, etc.?

We already do ADSL so it would be nice to have the wireless customers use the same infrastructure to keep things easily managed. Also, I'm not sure if StarOS would support it (especially in this circumstance) but some APs have the ability to not relay traffic between clients -- perfect, I would think, for extra security in a PPPoE over VDS situation.

Is a workable practice or not recommended? If so, what kind of limitations as far as bridged VDS nodes per LAC?

If this is a no go, could StarOS someday be upgraded to operate as a LAC for PPPoE sessions but forward the L2TP session to a remote LNS for termination?

Thanks,
Mark

[DrLove73]

You could forward/redirect all PPPoE traffic/query up to your main PPPoE server. With any setup.

As I understand, VDS puts great stress on both sides of the VDS link. WAR1 should be able to do their part, but server(s) in your office would probably be some x86 PC CPU monsters. VNC guys can tell you exacly how much CPU power would it take.

Clients that are connected directly to same WiFi card cannot see each other unless you turn on InterBSS Reley, something about networking aproach in linux kernel thinks that if they are on the same interface and same subnet, they should already see each other, so it does not route them thru.

Blocking other subnets of seeing each other can be done by firewall rules or by handing out public IP addresses directly to clients unit.

Switching users with same static IP among diferent interfaces/PoP's is not possible, due to routing/subnet design. Only bridge ALL of your network into one subnet could do that, but that is BAD practice, so....

I think that best practice for authentication would be if Star-OS could somehow authenticate users MAC, assign him IP and cbq rules from radius and then create PPoE? session to the main LAC for routing purposes. But Star-OS can not do that at the moment.

[lonnie]

PPPoE is basically a radius server that talks to some remote system to provide the actual control. You can have the radius provide the IP and bandwidth or let the PPPoE Server use defaults.

My advice would be the PPPoE Server at each AP. It does mean a bit of setup on each AP but once it is done it will rarely change.

VDS imposes a load due to having to repackage the data and send it out. Even a WAR1 with VDS has enough throughput for a normal client (4 to 5 mbps), so with the extra load or not it is still a viable alternative.

[DrLove73]

I meant mostly to warn his on other part of the links, so he would not use WAR4 or some old PC in his office for termination. I am correct, right?

[lonnie]

It is quite acceptable to use a PPPoE server at the client side, so a WAR2/4 or older PC would be fine for the task.

My preference is to provide the control just before the client connection, so that if I shut them down they cannot get any traffic onto my LAN.

[DrLove73]

No, no, the VDS side/termination point. If he creates couple hundread (or thousand) VDS links (for each customer), termination machine (NOC?) for all those links should be regular beast?

[lonnie]

The VDS termination should be a powerful x86 PC and then it can handle the load. Currently there is a limit but we are testing a change that will be nearly unlimited.

VDS was meant to provide for linking two networks using any old network in between. Mostly we envisioned it as a VPN to connect several offices and be able to shate files and printers, etc.

[markscs]

Yeah, I'm not going to both with PPPoE if I can't send all the sessions back to a LNS at the NOC. It lets me grow the wireless network infrastrucutre, and just add blocks of public addresses to the LNS which can be shared amongst all DSL LACs and wireless APs.

Any chance StarOS' PPPoE server can be set up to act as a LAC? This to me, seems to be the cleanest way to give everyone public IPs (or static IPs) without wasting IPs.

The second best way would be to use VDS (or at least until the above can be accomplished). So if I understand this right, I turn off Intra-BSS relay, and I can VDS each wpci interface to a large(cpu-wise) VDS termination box back at the noc, drop that onto an ethernet segment that can see a LAC and then it will send my sessions to the LNS as I would like to do above?

I'm NOT using staros CPE, so I need to have the CUSTOMER FACING wpci interfaces on the AP in a sense "bridged" to a LAC at the NOC (which if I'm understanding right can be done by VDS)?

[markscs]

You could forward/redirect all PPPoE traffic/query up to your main PPPoE server. With any setup.


How do I do that without bridging, since PPPoE is layer2?

[markscs]

PPPoE is basically a radius server that talks to some remote system to provide the actual control. You can have the radius provide the IP and bandwidth or let the PPPoE Server use defaults.

My advice would be the PPPoE Server at each AP. It does mean a bit of setup on each AP but once it is done it will rarely change.

VDS imposes a load due to having to repackage the data and send it out. Even a WAR1 with VDS has enough throughput for a normal client (4 to 5 mbps), so with the extra load or not it is still a viable alternative.

I understand what a PPPoE server does, BUT, then I'm stuck with wasting a lot of public IPs, or having to change customers' static IPs on a regular basis as our client-base grows. (eg an AP starts with a /28 but then we need to grow it to a /27 etc. fine if no one has a static IP, hell if they do, AND I'm wasting alot of IPs that are not being used).

If the AP could just act as a LAC and forward the PPPoE session back to the LNS as an l2tp session it would be perfect. This is how most DSL systems are deployed.

All customer routers support it (unlike PPTP) and it's easy for my staff to support because we're already doing it for DSL -- the wireless client bridge functions the same as a DSL modem from the customers perspective.

I just don't understand how you guys are doing it right now to support hundreds (thousands?) of customers. Either you're having to waste IPs like crazy in a routed public IP environment(even if you're using private IPs for your backbone), deny your customers public IP addresses (I fully realize that 99% of the time they don't need a public IP but I want to be offering "real" Internet the same as DSL and cable), or creating a huge bridged mess. Unless I'm missing something.

We've just re-started our wireless growth (we have only had about 50 wireless customers for years and focused on DSL the last few years, so bridging the whole wireless network to a DHCP server has worked fine for us) and expanding the network to cover many small rural communities, I want to do it once and do it right. :)

Thanks for your help and input guys.

-Mark

[lonnie]

If you used a VDS tunnel from the AP back to the POP then the customer packet would be available at layer 2 for your own own services. If you use our CPE then it will bridge the customer Ethernet to the AP and if you are using another CPE then it is a pseudo bridge, but should still work.

This approach will keep your backbone off limits to any hacking.

[markscs]

If you used a VDS tunnel from the AP back to the POP then the customer packet would be available at layer 2 for your own own services. If you use our CPE then it will bridge the customer Ethernet to the AP and if you are using another CPE then it is a pseudo bridge, but should still work.

This approach will keep your backbone off limits to any hacking.

Perfect. (until/if you build LAC support into staros :-)

So what do I need to make a "big" VDS termination box that could terminate VDS sessions from say... 10-15 APs (each AP having 1-2 client facing wpci radios)?

Thanks!

-Mark

[lonnie]

The old ATX-733 boards make great servers that purpose. You can use all the way to core2 duo boards, which are not all that expensive anymore.