Re: Dialup over Ethernet

Sam Silvester <[email protected]>
Newsgroups gmane.org.operators.nznog
Message-ID <CAAAhk69_PWzZrVJV_e4Sjj1bzxMj5nFwqiQM7KjQLqRRfN=zug@mail.gmail.com>
On Wed, Sep 13, 2017 at 3:23 PM, Ewen McNeill <nznog-g+LI5CTLdeyVez4R2NBCHqU/[email protected]>
wrote:

> A client had a (business) customer switch over to UFB and needed
> assistance reconfiguring the (Mikrotik) router being attached to the ONT --
> it turned out whoever first set up the Mikrotik (sensibly) assumed it'd be
> seeing IP packets over VLAN 10, but actually the ISP required IP packets
> over PPPoE over VLAN 10 in order for it to work.
>
> Looking around it appears this client's customer's ISP isn't the only one
> that is requiring PPPoE over VLAN tagging over Ethernet for their UFB
> connections.  Is there a reason other than "let's make everything look like
> 1990s dialup so it works with our legacy equipment" for the bit/CPE CPU
> overhead of PPPoE on UFB, including imposing the lowered usable MTU and
> PMTU discovery headaches on the end user?
>
>
*waves from over the ditch*

I notice you said a business customer - for that reason alone, my usual
expectation for the handoff of a service would be either a tagged or
untagged IPoE service - likely statically configured (not DHCP).

In the case of a 'business plan on a residential-grade service', something
I've often seen marketed as "SOHO" or some kind of 'business pack' you can
add-on to a residential service, then I'd be less surprised to see the
service delivered using the same methodology as a residential service
(either PPPoE or IPoE using DHCP). I guess it makes sense if you are an ISP
and already have the infrastructure to deliver one or the other to keep
doing that.

The other consideration I'd put out there for PPP is that in the
'residential grade service dressed up as a business product', I've seen
lots of ISPs make use of broadband aggregation features such as quotas and
differentiated billing/traffic metering (e.g. "free traffic for content
delivered via our local mirror, or with a given DSCP value"), shaping users
after a given quota, making use of walled gardens/captive portal pages to
redirect users with expired accounts or for payment details.

A lot of those features (at least in Cisco land) were much easier to
implement when you had a technology like PPP giving the customer connection
state and a logical interface on the broadband aggregation box to work
with. I know in Cisco's ISG there was a theory of treating customers
attaching via a variety of technologies the same, but I think many people
that have used ISG would be likely to agree that while it's a great idea in
theory, the reality is not quite the case.

From my experiences, I think the ability of PPP to give the impression of a
stateful, point-to-point link for each customer over a shared aggregation
network seems to be a massive boon, well worth the overhead.

The only time I think it wouldn't make sense is on top of a true business
grade connection where the user already has a dedicated VLAN/broadcast
domain/bridge group/whatever naming suits to themselves.

Cheers,

Sam

_______________________________________________
NZNOG mailing list
[email protected]
https://list.waikato.ac.nz/mailman/listinfo/nznog
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.