PPPoE vs IPoE shared mode advice

Questions related to general functionality
Post Reply
zash
Posts: 12
Joined: 03 Apr 2016, 22:17

PPPoE vs IPoE shared mode advice

Post by zash »

Hi.

For years I have been using only PPPoE. My network consists of wireless (ubiquiti gear, aps and cpes) and GPON (huawei olts and onts).

Now I don't have much problems with PPPoE but I have been increasingly thinking of moving the GPON portion of the network to IPOE shared mode (L2).

I am trying to come up with pros and cons:

benefits of IPOE:
a) Plug and play. Much easier for customers, no fiddling with usernames and passwords. Although most of the time we provide our own routers
b) MTU 1500. Less problems and complaints of slow VPNs (if someone is unaware that he has to adjust his tunnel's mtu to account for pppoe). In addition the huawei gear I use does not support 1500 mtu pppoe.
c) Potentially better performance with ipoe, besides the higher MTU it might work better with linux networking RSS?

cons of IPOE:
a) Worse failure detection. For example, if customer's router keeps rebooting for any reason (e.g bad power supply) this won't be visible in radius sessions because even a small dhcp lease probably won't expire.
b) Potentially more difficult to implement dual-stack (not using ipv6 so far, though), although I don't know if this applies to ipoe shared mode.
c) Load balancing a bit more difficult than with PPPoE. Not only do you add a new bras to terminate sessions, you need to provide IP addresses for gateways, but it's a minor inconvinience.

For PPPOE there is quite some linux adjusting and tuning that needs to be done for proper performance, like RPS. Would this be necessary for IPOE also, or would RSS benefit IPOE?

What would be an optimal DHCP lease for IPOE? In one way it should be low, in case if a bras crashes (very rare, but can happen) so that in such scenario customers routers' request a new lease quite soon (most people rarely restart their routers if things go bad...). But at the same time wouldn't a low dhcp lease time bombard accel-ppp too much and cause some issues?

In principle PPPoE and IPoE work very much the same from accel-ppp's perspective so I am wondering if the benefits are worth it. What would you advice? Would it be a good idea to move to IPOE from PPPOE for the GPON network? Anything else I should consider or know?

Thanks.
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: PPPoE vs IPoE shared mode advice

Post by dimka88 »

Hi Zash, why not use VPU (vlan per user) e.g. qinq. Most OLT allow this.
In general you dont need enable RPS for non encapsulation traffic like QinQ or PPPoE
The optimal DHCP lease around 300 sec (5 min) and renew time 1/2 e.g 150 sec
In most modern networks to many ISPs use IPoE for G/GEPON.
zash
Posts: 12
Joined: 03 Apr 2016, 22:17

Re: PPPoE vs IPoE shared mode advice

Post by zash »

Hi,

Reasons against QINQ in my case:
a) ugly configuration on huawei gear
b) more complex configuration in general: vlan-mon etc.
c) possibly requires special drivers like these? https://github.com/serhepopovych/ixgbe

but it does provide the best separation

Huawei gear supports smart vlan feature, where onts cannot communicate with each other.
Pros for this case
a) can use normal vlans
b) easier configuration
c) for protection and preventing customers from cheating i can use option82 and mac security on huawei gear
d) if i want communication between users i can use proxy-arp=2 in accel and some firewall rules


the question is, is there any benefit with a qinq setup that would be more performant than the l2 shared mode or no?

thanks
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: PPPoE vs IPoE shared mode advice

Post by dimka88 »

Hi.

c) It is good to use RPS without patching driver
the question is, is there any benefit with a qinq setup that would be more performant than the l2 shared mode or no?
In general no, except better isolation (vlan per user) and in this case you do not need any additional features like 82 options which sometimes is buggy on some vendors
Post Reply