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 P
I'm firmly in the PPP Must Die camp.
As far as I can make out, PPPoE is a thing because ISPs built PPP &
Radius infrastructure for dial-up, used it to for ADSL (because that was
the only way Telecom would let you do it), and continue to use the same
back-end stuff to drive PPPoE for ADSL, VDSL
Hi Ewan,
> On 13/09/2017, at 3:53 PM, Ewen McNeill 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
>
ntil then I am
completely sold on PPPoE vs IPoE.
Sent from my phone so excuse the brevity.
---- Original Message
Subject: Re: [nznog] Dialup over Ethernet
From: Don Stokes
To: nznog@list.waikato.ac.nz
CC:
I'm firmly in the PPP Must Die camp.
As far as I can make out, PPPoE is
[Reordering quotes for readability]
On 13/09/17 18:18, Don Stokes wrote:
I don't believe anyone is actually using usernames/passwords
to identify customers any more, but I won't be surprised if I'm wrong.
It's not like dial-up where the customer could be coming from anywhere.
Part of what pro
On 13/09/17 18:21, Nathan Ward wrote:
In both EUBA and UFB, Chorus or the LFC inserts a headers in to the
DHCP or PPPoE messages that convey the Circuit ID and Remote ID.
Remote ID is the most commonly used for authentication and corresponds
to a provider reference number (ASID in Chorus world, f
On 13 September 2017 at 19:03, Ewen McNeill
wrote:
>
> Part of what prompted my surprise is that this Mikrotik very much did have
> a username and password on the PPPoE configuration, apparently given to my
> client (setting it up for their customer) by the ISP in question -- and the
> password l
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
use the brevity.
---- Original Message ----
Subject: Re: [nznog] Dialup over Ethernet
From: Don Stokes
To: nznog@list.waikato.ac.nz
CC:
I'm firmly in the PPP Must Die
camp.
As far as I can
need QoS then no need for VLAN 10.
> But once you've gone down the tagged route it's hard to move back as then
> you have a customer config nightmare.
>
> Find arguments against the above and I may listen. But until then I am
> completely sold on PPPoE vs IPoE.
>
> Sen
, 14 September 2017 9:06 a.m.
To: Brian Gibbons
Cc: nznog@list.waikato.ac.nz
Subject: Re: [nznog] Dialup over Ethernet
I'm of the same opinion as Peter on this. I'm firmly in the PPPoE camp.
Generally speaking the only real case of opposition is the MTU at 1492. However
in saying t
Chiming in here..
On Thu, Sep 14, 2017 at 9:05 AM, Hamish McGlinn wrote:
> I'm of the same opinion as Peter on this. I'm firmly in the PPPoE camp.
>
> Generally speaking the only real case of opposition is the MTU at 1492.
> However in saying this I feel like it is a non issue with mss adjustmen
On 14/09/17 09:38, Dave Mill wrote:
And then send those packets through a TCP MSS adjuster. This works well
for the rare case where the customer can't do it.
Really, the 1492 packet size is just a non issue.
I guess the Internet really is only TCP these days... and presumably
soon only TCP/4
On 09/14/17 10:16, Ewen McNeill wrote:
> On 14/09/17 09:38, Dave Mill wrote:
>> And then send those packets through a TCP MSS adjuster. This works
>> well for the rare case where the customer can't do it.
>>
>> Really, the 1492 packet size is just a non issue.
>
> I guess the Internet really is on
On Wed, Sep 13, 2017 at 3:23 PM, Ewen McNeill
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 ov
On 14/09/17 09:33, Peter Lambrechtsen wrote:
For me the restore time in the event of loss of service to customers is
the main reason why PPPoE is superior to DHCP/IPoE.
Thanks for all the details.
I do remain puzzled by the use of a stateful protocol (PPPoE) with a
timeout (LCP keepalive) lea
On 14/09/17 09:38, Dave Mill wrote:
Really, the 1492 packet size is just a non issue.
FWIW, in case people didn't see these APNIC blog posts last month,
there's a risk of this ending up being an IPv6/UDP issue:
https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
https://blog.ap
17 matches
Mail list logo
