R1------------\ | \ ibgp ISP R3 | / R2------------/
+-------------- ISP_R1 -+
| EBGP |
R1-+ | IBGP
| EBGP |
+-------------- ISP_R2 -+
> /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 0.0.0.0/0 212.25.9.1 20
1 Db 0.0.0.0/0 212.25.9.2 20
# feb/02/1970 15:21:57 by RouterOS 6.7
# software id = XHEM-GX3Y
#
/interface vlan
add comment="CES" interface=sfp1 l2mtu=4070 mtu=4000 name=sfp1-ces vlan-id=3214
/ip neighbor discovery
set sfp1-ces comment="CES"
/interface wireless security-profiles
/routing bgp instance
set default as=64512 router-id=z.y.x.w
add address=z.y.x.w/26 interface=sfp1-ces network=z.y.x.0
/routing bgp network
add network=a.b.c.d/27 synchronize=no
/routing bgp peer
add name=peerA remote-address=z.y.x.1 remote-as=8758 ttl=default update-source=sfp1-ces
add name=peerB remote-address=z.y.x.2 remote-as=8758 ttl=default update-source=sfp1-ces
More than four (4) years since my initial post, and still there is no proper ECMP support ...
I've been wanting to see this as well, but i'd rather have recursive routing in IPv6 for BGP fixed first.
But that is the idea of ECMP.... have 2 or more routes for the same prefix pointing to a different path, and the router has some mechanism to use them alternately for outgoing traffic.Second thing to observe is, you will get never ever on any router 2 routes active pointing to the same destination prefix.
I solved this for me with Routing Filters under Set Next-Hop-in with multiple Gateway-Addresses. This works for me even for BGP.
It is even worse. RouterOS "BGP" (I am using quotes because it is not RFC 4271 compliant) picks not just the first gateway for equal cost routes, but even for UNEQUAL cost routes, since it does not care whatsoever for IGP costs to reach the BGP next hop gateway. This not only violates RFC 4271 but essentially also means that RouterOS routes packets in an BGP or MPLS cloud essentially in a random fashion. Yes, packets reach the target, but to go from New York to Boston, RouterOS first sends you first to Los Angeles, then Seattle, detour through Chicago, and then to Boston, since its "BGP" has no understanding of the IGP topology in an AS.with that said, i'd really like to have ECMP supported in MPLS LDP. it's really weird that it works fine with OSPF but when you run LDP on top of it it just picks whatever gateway is listed first on the route, this is terrible for load-balancing VPLS.
That became clear to me pretty quickly when I started using RouterOS BGP, and I quickly decided to use a different AS number for every site.It is even worse. RouterOS "BGP" (I am using quotes because it is not RFC 4271 compliant) picks not just the first gateway for equal cost routes, but even for UNEQUAL cost routes, since it does not care whatsoever for IGP costs to reach the BGP next hop gateway. This not only violates RFC 4271 but essentially also means that RouterOS routes packets in an BGP or MPLS cloud essentially in a random fashion. Yes, packets reach the target, but to go from New York to Boston, RouterOS first sends you first to Los Angeles, then Seattle, detour through Chicago, and then to Boston, since its "BGP" has no understanding of the IGP topology in an AS.
I just need OSPF route conversion from v6 and then I'm golden.It's on the roadmap for protocol support in the v7 status page
https://help.mikrotik.com/docs/display/ ... col+Status
Mikrotik spent years putting the groundwork in place, building the framework for the new routing engine to ensure it would scale and be easy to maintain. They also hired a bunch more developers.Thanks. Not very hopeful on it being any time soon since v7 has been in the works for years now :'(
Its a big software dev problem I come across it all the time - 80% of the work is background "do-nothing" code (to a customer perspective) so the 20% of the frontend is super quick, zippy, easy to add and remove things, make it modular etc. Once you get over that hump it becomes so much quicker.Mikrotik spent years putting the groundwork in place, building the framework for the new routing engine to ensure it would scale and be easy to maintain. They also hired a bunch more developers.Thanks. Not very hopeful on it being any time soon since v7 has been in the works for years now :'(
You might be surprised at how quickly features are added from this point forward...
Well that would be real nice if this could move to a stable release real soon. ROS has just felt stagnant for the last couple years. Hardware moving forward while the os at stand still.Mikrotik spent years putting the groundwork in place, building the framework for the new routing engine to ensure it would scale and be easy to maintain. They also hired a bunch more developers.Thanks. Not very hopeful on it being any time soon since v7 has been in the works for years now :'(
You might be surprised at how quickly features are added from this point forward...
You must not have been paying much attention!Well that would be real nice if this could move to a stable release real soon. ROS has just felt stagnant for the last couple years. Hardware moving forward while the os at stand still.Mikrotik spent years putting the groundwork in place, building the framework for the new routing engine to ensure it would scale and be easy to maintain. They also hired a bunch more developers.Thanks. Not very hopeful on it being any time soon since v7 has been in the works for years now :'(
You might be surprised at how quickly features are added from this point forward...
In fairness, their routers are dirt cheap even by consumer router standards and offer massive value *even without* BGP ECMP. I'd like to see it, too. But their devices aren't exactly priced to support a rapid pace of development while remaining stable, either.Well that would be real nice if this could move to a stable release real soon. ROS has just felt stagnant for the last couple years. Hardware moving forward while the os at stand still.Mikrotik spent years putting the groundwork in place, building the framework for the new routing engine to ensure it would scale and be easy to maintain. They also hired a bunch more developers.Thanks. Not very hopeful on it being any time soon since v7 has been in the works for years now :'(
You might be surprised at how quickly features are added from this point forward...
More than four (4) years since my initial post, and still there is no proper ECMP support ...