Re: Dialup over Ethernet

On 13/09/17 18:38, Peter Lambrechtsen wrote:
> You can change customers IP addresses easily by just kicking them and 
> they come back in worst case 90 seconds 

Out of curiosity what is the use case for "disconnect user to force them 
to change the IP address"?  If it's changing from dynamic pool to 
"congratulations you've bought the static IP service" then the phrase 
"please reboot your CPE now" comes to mind (perhaps combined with a DHCP 
server that will refuse a renew of a dynamic lease when it has a static 
lease configured).

> No support for username and password so if your friendly LFC has screwed 
> up the provisioning so you can't auth them on RID/CID you can't ask your 
> customer to put in "heyfindme" in their username on the router and they 
> magically appear in the radius logs and then tell the LFC to sort it.

Wouldn't another DCHP option work for that?  Or reuse of an existing one?

Enterprise DHCP clients commonly sends a hostname in an extension (12 
IIRC) which turns up at the DHCP server, and is often configurable on 
devices.  Perhaps "home gateway" CPEs don't support that, but that too 
seems like an obvious thing to specify in the "desired CPE".  (Although 
at the point the user is logged into the CPE to put something in, surely 
they can read you the WAN MAC address too...)

> All LFCs support 1508 MTU so if your router and BNG does it then you can 
> get a full 1500 sized packets which you can on Spark.

That at least is good to know.  It doesn't seem to be as well documented 
as it could be.  Eg, as a random end-user-facing third party guide:

https://www.geekzone.co.nz/forums.asp?forumid=66&topicid=206084

suggests configuring ether1.10 (ie, VLAN 10 on 
interface-intended-to-be-WAN) as 1500 byte MTU... then PPPoE over that.

> Find arguments against the above and I may listen. But until then I am 
> completely sold on PPPoE vs IPoE.

So far I'm not convinced there's much being gained by PPPoE that 
couldn't have been solved by requiring a CPE with a couple more simple 
features (BFD, DHCP hostname support, maybe something to assist a PVLAN 
like deployment).

It seems like typical CPE chipsets will do VLAN tagging in hardware, but 
PPPoE seems to end up being done in the "supervisor" CPU -- which means 
with PPPoE the CPU speed of the device is a limiting factor on 
throughput (and/or CPEs have to have higher end CPUs for the same 
throughput).  I guess eventually someone could build CPE chipsets that 
do PPPoE encapsulation in hardware (and presumably BNGs have such 
chipsets), but even if you do that you've still got 8-octets-per-frame 
additional overhead.  That's more than a whole ATM cell right there.... :-)

Ewen

PS: Thanks everyone for the quick replies.  It's at least useful to see 
there's _something_ being obtained from the PPPoE overhead other than 
authentication.  Even if I don't think it's the most sensible way to 
obtain those extra features.