I am currently bonding two FTTC PPPOE circuits using 2 x WAN IP’s (supplied over PPPOE) which both route the same /29 between my ISP and my routerboard. To achieve the bonding upstream (outbound from routerboard to ISP) I am using a mangle rule (eg 1of2, 2of2 Nth) to alternate packets between two newly marked WAN routes, and use srcNAT from my LAN using one of the /29 addresses. This works ok but I have only been able to bond my LAN addressing, I have not been able to bond the router data itself (i.e. the OUTPUT chain) which uses the unmarked route, so the DNS lookups from the router are not bonded.
Is there a way of bonding the router input/output easily? If I try to use the main mangle rules I created for the bonding, and route mark all traffic, nothing works…
Slightly off topic, the word “bonding” is usually used in a specific meaning, which is aggregation of physical (or at least L2-transparent) links.
There is a caveat when policy-routing router’s own traffic. The order of actions is the following:
route the packet using routing table main
assign it a source address depending on the chosen route
eventually assign a routing-mark in chain output of mangle
if routing-mark has been assigned, the packet is routed again, but its src-address is not changed
eventually change the source address in chain srcnat of nat
So unless a rule in your srcnat chain handles the traffic sent by the router itself, the packets leave with the IP of the WAN chosen by table main, and thus those which actually leave through the “wrong” WAN may be dropped by the ISP depending on their policy.
I think one issue that I’m having is that when I try to send the router output traffic over both links by alternating packets, I’m disrupting the two individual PPP sessions which are WAN/link specific. I guess what i need to do is find a way of sending all router (output) traffic EXCEPT the traffic used to create and sustain the PPP sessions, which needs to not be split across the two links, if this makes sense?
Nope, the IP firewall and IP routing doesn’t affect the PPPoE transport frames as they are not IP ones themselves (IP packets are encapsulated into them). So the root cause must be something else. Post the export of the configuration, see my automatic signature below regarding proper obfuscation of sensitive information.
Are the WAN IPs assigned via PPPoE public ones or CGNAT ones (from the 100.64.0.0/10 subnet)?