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.