http://wiki.mikrotik.com/wiki/Manual:BG ... _with_eBGP describes how to achieve load balancing per-flow. It is however a rather complicated setup.

I tried to use the much simpler solution of just adding the second router as two eBGP peers on two different interfaces.

/routing bgp peer
add name=peer1 remote-address=10.251.1.2 remote-as=65252
add name=peer2 remote-address=10.251.2.2 remote-as=65252

10.251.1.2 and 10.251.2.2 are both actually the same router.

This worked, almost. The sessions come up, the routes are installed:

8 ADb dst-address=10.251.9.0/24 gateway=10.251.1.2 gateway-status=10.251.1.2 reachable via ether1 distance=20 scope=40 target-scope=10 bgp-as-path="65252" bgp-origin=igp received-from=peer1
9 Db dst-address=10.251.9.0/24 gateway=10.251.2.2 gateway-status=10.251.2.2 reachable via ether2 distance=20 scope=40 target-scope=10 bgp-as-path="65252" bgp-origin=igp received-from=peer2

However, as you can see only one of the routes are actually installed into the kernel routing table.

On other systems like JunOS there is a knob to twist to make the router install all completely equal routes into the kernel routing table. I cannot find a similar knob for RouterOS. The only way to actually get two routes into the routing table is this one:

/ip route add dst-address=10.251.10.0/24 gateway=10.251.1.2,10.251.2.2
10 A S dst-address=10.251.10.0/24 gateway=10.251.1.2,10.251.2.2 gateway-status=10.251.1.2 reachable via ether1,10.251.2.2 reachable via ether2 distance=1 scope=30 target-scope=10

It would be really handy if that could be fixed... I.e. if both gateways are reachable, distance and scope and target-scope are identical, install both routes.

I have tested with RouterOS 5.24 and 6.0rc13.

Considering that most of your competitors can do it, "by design" is not very convincing. But fair enough, choices are the good thing about competition

Insinuating that I have not read the RFC is not particularly helpful either. The RFC tells how to select the best path which is advertised to other peers. It does not specify which routes you put into the hardware forwarding table, that is a policy decision which is outside the scope of the RFC protocol.

It has been a long time since I did the test on Cisco; it is not a vendor we use much anymore. Nevertheless, here is the documentation link for doing with Cisco exactly what I do on JunOS: http://www.cisco.com/en/US/tech/tk365/t ... html#conf2

Notice the simple configuration and the lack of static routes or multi-hop.

Hostility towards customer input is sadly a staple when dealing with Mikrotik.