“So, maybe EOIP should’nt be changed, but PPTP should be supported by bonding…”
Why not, but MLPPP would be more appropriate and more reliable.
Bonding has been designed primarily to connect Linux machines to switches or other Linux Machines on the LAN. It is not optimized for WAN connections.The first product to easily support bonding / openvpn was Zeroshell. There are lots of users on the Zeroshell forum having problems with this.
Most bonding modes (there are 7 modes if i remember well) seems to not work optimaly on EoIP WAN links. Only active backup is fully working. Users are reporting bandwith problems with other modes (specially with TCP) as soon as the bandwith on each link is different, because packets do not arrive in the right order. Only 802.3ad mode guarantee that packects arrive in order, but each channel need to have exactly the same bandwith. So it is not usable on most WAN links.
MLPPP can be used not only with pppoe, but PPTP or L2TP as well.
Last, i’ve found that bonding EoIP in active backup mode is only interesting if you need a very fast commutation time between active and backup link. But to get this fast commutation time, about 50 ms like for SDH links, you need something like a 20 ms arp frequency. This is quite a high bandwith overhead for slow links.
Nevertheless, i’m using this to secure Internet links through different providers when commutation time is critical and we can’t change seen gateway. (linux NAT and connection traking does not like changing gateways, generaly it does break VoIP trafic until you reset the connection tracking table regardless the router you are using).
For looser commutation time requirements, we can use two PPTP tunnels, with static routes to them (using server PPTP interfaces). We’ll give a higher metric for the backup link.
For bridging, RSTP or Mesh interfaces should be usable. I didn’t tried this, but i tried PPTP alone with BCP bridging, seems to work flowlessly, and we can rise the MTU to 1500, thanks to the MRRU setting, (using MLPPP single link internaly) even if the pptp links are setup on a PPPoE xDSL link.
I hope to see MLPPP server on Mikrotik soon. Then we’ll begin to have a really serious small provider router, and we’ll be able to start comparing with Cisco, Juniper or Nortel entry offers.
Actually and unfortunately, there is still a big difference between big names and alternatives like Avaya or Mikrotik. Except the hardware power higher on big names box, PDH / SDH / ATM full support, and premium paid support, low price alternative products do not support complex or recent functions like MLPPP or Provider Backbone Bridge.
There is no reasons products like Mikrotik do not take more Cisco market parts. With the arrival of Intel / Broadcom multiqueue Network cards and multi core PC systems, Linux routing systems will become more and more competitive and attractive compared to Asic hardware. But to achieve this they must make a real developpement effort to support advanced functions needed by providers.
Provider Backbone Bridge is implemented since about two years by Cisco/ Juniper / Nortel. We don’t see it in the Linux world. This is the problem. When you are a provider, you can’t wait years to have the technology of your competitors. That’s why there is still a market for the leaders, even if Linux boxes are ten times lower cost.
