RouterOS v7 installs ECMP for iBGP routes although documentation says multipath is not supported

RouterOS Forwarding Protocols
1

Hello,

I am observing unexpected ECMP behavior in RouterOS v7 that seems to contradict both standard BGP behavior and MikroTik documentation.

According to MikroTik documentation:

“Multipath is not supported”

However, the behavior I am seeing goes beyond normal “equal-cost” routing.

Environment

RouterOS v7.x (same version on all devices)

Platforms:

CHR

CCR1036

Same BGP configuration and routing filters

Observed behavior on CHR

For a single prefix (example: 192.168.1.1/32), three iBGP routes exist:

Route A: LOCAL_PREF 100 → inactive

Route B: LOCAL_PREF 100 → active (ECMP)

Route C: LOCAL_PREF 99 → active (ECMP)

So:

Two routes are installed as ECMP

These two routes have different LOCAL_PREF values

One route with the same LOCAL_PREF as an active route is excluded

This means ECMP is created:

Not only without equal LOCAL_PREF

But also inconsistently across otherwise identical routes

Observed behavior on CCR1036

With the same RouterOS version and configuration:

Only one best path is installed

No ECMP occurs

Why this is problematic

LOCAL_PREF is ignored for ECMP grouping

ECMP is created across unequal BGP attributes

Behavior differs between CHR and CCR

Documentation states multipath is not supported

This causes unintended traffic splitting

Questions

Is ECMP across iBGP routes with different LOCAL_PREF values expected behavior?

If yes, why does documentation state that multipath is not supported?

Why does CHR behave differently from CCR with identical config?

What is the officially supported way to guarantee single-path iBGP forwarding?

At the moment, the only reliable workaround seems to be explicitly disabling multipath on iBGP sessions or enforcing different administrative distances.

I would appreciate clarification from MikroTik staff.

Thank you.

2

The best path algorithm also compares routes received only by a single BGP instance. Routes installed by different BGP instances are compared by the general algorithm, i.e. route distances are compared and the route with a lower distance is preferred.

3

photo_2025-12-28_17-07-01
photo_2025-12-28_17-07-01520×204 20.8 KB

photo_2025-12-28_17-07-09
photo_2025-12-28_17-07-09532×218 20.2 KB

first one on chr 7.20.6 second one on CCR1063 7.20.6

4

“The path with highest LOCAL_PREF is chosen over lower LOCAL_PREF.”

5

As already mentioned, for bgp best path to work peers that receive the routes must be from the same instance.

6

Based on your response, I tested the behavior further and can confirm the following:

  • When routes are learned from peers within the same BGP instance, the BGP best path selection algorithm behaves as expected and ECMP is not created.

  • When routes are learned from different BGP instances, they are not compared by the BGP best path selection algorithm.

  • As a result, routes from different instances can be installed simultaneously in the routing table as ECMP, even when LOCAL_PREF values differ.

This confirms that in RouterOS v7, BGP best-path selection is instance-scoped, not global.

To better understand the intended behavior, could you please clarify the following:

Does RouterOS support BGP multipath within the same BGP instance?

  • If multipath is supported within an instance, under what exact conditions is ECMP expected to be installed?

  • If multipath is not supported, how should users interpret scenarios where multiple routes from different instances are installed as ECMP in the main routing table?

It would be very helpful if the documentation explicitly stated:

  • That BGP best-path selection applies only within a single BGP instance

  • That attributes such as LOCAL_PREF are not evaluated across instances

  • That using multiple BGP instances feeding the same routing table may result in ECMP

This distinction is critical for deterministic routing designs such as anycast and multi-POP deployments.

Thank you for your time and clarification.

7

I would like to clarify the behavior we are observing, as it appears to differ from standard BGP best-path expectations.

In our testing, when the same prefix is received from different peers that belong to different BGP instances, RouterOS installs multiple active routes into the routing table and performs ECMP, even though the paths have different BGP attributes (AS-PATH length, Local Preference, and MED).

As we understand it, this happens because best-path selection is performed independently per BGP instance. Since each instance sees its own path as the best, multiple routes with equal administrative distance are exported to the main routing table, where the kernel installs them as ECMP routes. In this case, BGP attributes are no longer compared globally, and forwarding decisions are made purely at the routing table level.

While this explains the behavior, it effectively results in load sharing across paths that are not equal from a BGP policy perspective, which can be unexpected and potentially problematic for traffic engineering.

Could you please confirm:

  1. Whether this ECMP behavior across different BGP instances is expected by design in RouterOS

  2. Whether there is any mechanism (other than changing distance or using a single instance) to enforce global BGP best-path selection and prevent kernel ECMP in such scenarios

8

Why are you using multiple BGP instances, particularly in a situation where the same subnets are being advertised across multiple instances?

The whole point of instances with any routing protocol is to allow that protocol to make the best-path decisions based on all peers associated with that instance, then hand it to the router. By using multiple instances, you’re isolating half the information you want the routing protocol to “see” and leaving it up to the router’s super basic options.

It sounds like you’ve found the answer to your problem: either put all networks where you want BGP to handle the decision-making into once instance, or understand the limitations of using multiple instances and use the router’s decision-making algorithm (basically filters to manually alter the distance).

9

To clarify, this is not a production design and I am not intentionally using multiple BGP instances. This behavior was observed during controlled testing.

All peers are configured under the same BGP instance.

What I found is the following:

  • When the same prefix is already learned from an upstream peer

  • And I advertise that same prefix toward a second router using an address-list / Output Network filter on the peer

  • The second router installs the received route as ECMP alongside the existing route, even though BGP attributes (AS-PATH length, Local Preference, MED) are different

However:

  • If I remove the Output Network (address-list) configuration from the peer

  • And instead let the prefix be advertised normally

  • The route on the second router is installed as a single best path, with no ECMP

All of this occurs:

  • In the same BGP instance

This suggests that the use of Output Network / address-list advertisement changes how RouterOS treats the route internally, effectively bypassing or short-circuiting normal BGP best-path comparison and resulting in kernel ECMP behavior.

So while I fully agree that mixing instances for the same routing domain would be incorrect, this specific issue appears to be related to how RouterOS handles locally advertised prefixes via Output Network, not instance separation.

If this behavior is expected by design, it would be very helpful to have it explicitly documented, as it can easily lead to unintentional ECMP and policy violations even in single-instance BGP setups.

photo_2025-12-30_21-22-22
photo_2025-12-30_21-22-22555×365 46.4 KB

Topology summary:

  • Each worker advertises the same /32 anycast IP via iBGP to its local site router (edge).

  • Each site router:

    • Advertises the aggregated /24 via eBGP to the Internet.

    • Advertises the /32 routes via iBGP to the other site router for redundancy.

  • All peers are in the same BGP instance.

  • iBGP between edge routers is configured with:

    • redistribute=bgp

    • nexthop-choice=force-self

  • BGP multipath is not enabled.

The issue I observe is this:

When a /32 prefix learned from a local worker exists on an edge router, and the same /32 is also learned from the other edge router via iBGP using Output Network, the route is installed in the routing table as ECMP, even though this should be a backup path.

This happens because:

  • The route learned from the local worker

  • And the route learned from the remote edge

  • End up with the same distance and routing table

  • So the kernel installs them as ECMP

However, if I remove the Output Network configuration from the iBGP peer and let BGP advertise the route normally, the /32 is installed as a single best path, and ECMP does not occur.

So this does not appear to be related to:

  • Multiple BGP instances

  • Intentional ECMP

  • Or BGP multipath

It appears to be specifically related to how Output Network causes the route to be locally originated, which bypasses normal BGP best-path comparison and results in kernel-level ECMP when distances are equal.