I have one pppoe server and I need more internet for it. I have two wireless link to pppoe_server one of them have 100mb capacity and one of them is 130Mb. How can i use both of link to share bandwith ? I’m sharing small diagram and settings.
please help me to solve this query Router A
/routing ospf instance
set [ find default=yes ] router-id=10.255.255.1
/routing ospf interface
add authentication=simple authentication-key=somekey cost=10 interface=VLANtoRouterB network-type=broadcast
/routing ospf network
add area=backbone network=10.255.255.1/32
add area=backbone network=10.0.0.172/30
You could potentially EoIP tunnel from PPPoE server to Router A taking both paths (as thats where the separate paths converge) then using a bonding interface to bond the 2.
This would likely mean you lose the 30mbit on the 130mbit leg of the link, but being wireless you could run into more overhead loss with out of time packets hitting Router A (if the latency differs on one link)
Another option is to split your userbase using source based routing, i.e. some PPPoE users go via Link A, some PPPoE users go via Link B and try manually manage the load.
amt, I can’t specifically state what he means but here are some options.
Perform routing based on the source IP address assigned on the PPPoE server (Policy Based Routing)
Let’s say hypothetically your PPPoE assigns your customers IP addresses from the 192.168.254.0/24 network. If this is the case you can tell RouterOS to send packets sourced from 192.168.254.0/25 to the 130 MB link and packets sourced from 192.168.254.128/25 to the 100 MB link.
Create multiple PPPoE servers or termination points
Right now, all of your users connect to a single PPPoE server. All traffic destined for your customers goes to and from it. This has the advantage of a single point to manage your IP addressing and user information. It has the down side of being a single point of failure and a bottleneck for traffic.
A way to work with this is split your pool of addresses up and create PPPoE servers in different places of your network. Maybe 1 per tower. This would allow normal routing to take over at the tower with all of it’s benefits like link costing and pathing at layer 3 via a dynamic routing protocol like OSPF. Along with splitting your addressing pool up you can move your current PPPoE server closer to the upstream Internet and allow the tunnels to it be the ones that are diversified.
I’m not ultra familiar with the RouterOS PPPoE server but you should be able to target it at either a central RouterOS UserMan server or another RADIUS server like freeradius or MS NPS. This would keep your user management centralized for but your routing more distributed and resilient.
Drop PPPoE Altogether
This is likely the least feasible approach as most tooling is built around PPP but in theory you can deploy other technologies to manage customers and their connections. I think the wireless industry has a unique advantage in this field by having a CPE on almost all of their customers networks. Scripting can be leveraged to automate swapping a non-paying customer’s CPE to a remediation VLAN and back again. You can use other technologies like 802.1x paired with an existing RADIUS back-end, with or without certificates.
Personally, option 3 would be what I would do but I understand that’s not a situation everyone can roll with. As far as your particular question of “merging” your two links. You can either create a pair of EoIP tunnels and bond them like the first user said or use PBR like I indicated to achieve some cross link utilization. Other than that you need to look at the more architectural fixes like #2 and #3.
this is what I’m trying to do but I could not success … I tried to mangle and route /25 traffic over the other link but its not worked. What can it be the problem ? Or Mangle and routing mark is correct way for this ?
Yes exactly, but Im testing /26 to see effect
Also /26 enough for 20mb traffic on this pppoe_server. if this solution work with /26 I should see minimum 10mb on second link ether. But I see only few upload..
If you run torch on a router upstream towards “Link-1” do you see traffic sourced within 172.31.1.0/26? If not then PBR is working correctly and the users within the /26 are currently only generating the load you see on “Link-2.”
Just as a catch-all. I imagine the 172.31.1.0/26 network is you obfuscating the addressing. If it’s not and you’re an ISP that is handing out RFC1918 addressing due to limited public IPv4 addressing I’d encourage you to look at RFC6598 and the 100.64.0.0/10 address space. The reason I state that is you don’t want to be giving your customers addressing that could potentially overlap with their own networks if you don’t have to.
If traffic is assymetrical you’ll need tell upstream routers which path to send the destination traffic. Start with static routes for simplicity.
If we look at a hypothetical 172.31.1.0/24 and for ease just split it in half, 172.31.1.0/25 through Link-1 and 172.31.1.128/25 through Link-2.
Outbound traffic from PPPoE Customers:
We do the source based routing on the PPPoE server.
Inbound traffic to PPPoE Customers:
Start with static routes on RtrB. Send 172.31.1.0/25 to RtrC and send 172.31.1.128/25 to RtrD. Apply additional static routes to RtrC and RtrD only if necessary to stop it from flowing back up to RtrB.
But theese boards talk each other with ospf, can it be any problem if i add any static route to routers while they talk eachother with ospf. and after this settings do i still need mangle rule ?
The PBR component (mangle and route with mark) is for outbound traffic.
The static routes on RtrB and optionally RtrC and RtrD are for inbound traffic.
You need both in reality.
The static routes shouldn’t cause any harm within your environment. That said you may want to look at something that may handle the splitting of the prefixes cleaner. I’d have to think about if we can do it within the constraints of OSPF but iBGP should work without a problem for sure.
I will test it now but before test;
1- create mangle for 172.31.1.0/25 which will come from link-1 and mark route for making output from link-1 ?
2- create one mangle for 172.31.1.128/25 which will be come from link-2, to making output from link-2. ?
3- Further more, do i need to redistribute-static routes as-type-1 in ospf instance ?
are thesee correct ways ?
Hi idlemind,
thanks for your help, I did job as your said and it seems work. but I have some questions.
I add static route 172.31.1.0/24 at router B to show 172.31.1.0/24 rane on Router D(cause Link-2 to pppoe_server on routerD) and when i check /ip route on router D 172.31.1.0/24 range already dynamically added by ospf and shows me interface of Link-2(that’s what we need) so I’m not going to add new static route on Router D. should i still need to add static route at router D ?
On PPPoE server there is some public ip’s assigned by radius and one more /26 range pppoe pool, I create only one mangle for /24 ip range which is comes from Link-2( we route them manually) do I need magle rule for others?
